بی‌حالتی، انقضای حالت و انقضای تاریخچه

توانایی اجرای گره‌های اتریوم بر روی سخت‌افزار متوسط برای غیرمتمرکزسازی صحیح بسیار مهم است. دلیل آن این است که گره به کاربران این امکان را می‌دهد که بجای اعتماد به شخص ثالث در ارسال داده‌ها با انجام بررسی‌های رمزنگاری‌شده به‌طور مستقل اطلاعات را تأیید کنند. اجرای یک گره به کاربران اجازه می‌دهد تا به جای اعتماد به یک واسط، تراکنش ها را به‌طور مستقیم به شبکه همتابه همتای اتریوم ارسال کنند. اگر این مزایا تنها برای کابرانی که دارای سخت‌افزارهای گران قیمت هستند امکان‌پذیر باشد، غیرمتمرکزسازی ممکن نیست. درعوض، گره‌ها باید قادر به اجرا با تجهیزات حافظه و پردازشی بسیار معمول باشند به‌طوری که بتوانند بر روی تلفن‌های همراه، میکرو کامپیوترها یا درحد غیرقابل‌توجه بر روی کامپیوتر خانگی اجرا شوند.

امروزه، الزامات فضای دیسک بالا مانع اصلی دسترسی جامع به گره‌ها است. این در درجه اول، به دلیل نیاز به ذخیره‌سازی مقادیر قابل توجه داده‌های حالت اتریوم است. این داده‌های حالت شامل اطلاعات مهم مورد نیاز برای پردازش صحیح بلوک‌ها و تراکنش‌های جدید است. در زمان نگارش این مقاله، یک حافظه سریع 2 ترابایتی SSD برای اجرای یک گره کامل اتریوم مورد نیاز است. برای گره‌ای که داده‌های قدیمی را حذف نمی‌کند، حافظه مورد نیاز حدوداً 14 گیگابایت در هفته زیاد می‌شود، و گره‌های آرشیو که تمام داده‌ها را از زمان پیدایش بلاک اول ذخیره می‌کند، به 12 ترابایت نزدیک می‌شود (در زمان نگارش، فوریه 2023).

از هارد دیسک‌های ارزان‌تر می‌توان برای ذخیره‌سازی داده‌های قدیمی‌تر استفاده کرد، اما آنها برای همگام شدن با بلوک‌های ورودی جدید بسیار کند هستند. حفظ مدل‌های ذخیره‌سازی فعلی برای کلاینت‌ها درحالی‌که ذخیره‌سازی داده را ارزان‌تر و آسان‌تر می‌کند، تنها یک راه حل موقت و جزئی برای رفع این مشکل است، زیرا رشد حالت اتریوم «نامحدود» است، یعنی الزامات ذخیره‌سازی فقط می‌تواند افزایش یابد، و پیشرفت‌های فناوری همواره باید با رشد مستمر حالت همگام باشد. لذا، کلاینت‌ها باید راه‌های جدیدی برای تأیید بلوک‌ها و تراکنش‌ها پیدا کنند که متکی بر جستجوی داده‌ها از پایگاه‌های داده‌ای محلی نباشد.

کاهش حافظه مورد نیاز گره‌ها

راه‌های مختلفی برای کاهش مقدار داده ذخیره‌سازی مورد نیاز هر گره وجود دارد که هرکدام نیازمند بروزرسانی‌ها با اندازه مختلف در پروتکل اصلی اتریوم می‌باشند:

• انقضای تاریخچه: به گره‌ها امکان می‌دهد تا داده‌های حالت قدیمی‌تر از حالت بلوک‌های X را حذف کنند، اما چگونگی نحوه مدیریت داده‌های حالت توسط کلاینت‌ها اتریوم را تغییر نمی‌دهد
• انقضای حالت: اجازه می‌دهد داده‌های حالتی که به‌طور متداول استفاده نمی‌شوند غیرفعال شوند. کلاینت‌ها می‌توانند تا زمان فراخوانی مجدد، داده‌های غیرفعال را نادیده بگیرند.
• بی‌حالتی ضعیف: فقط ایجادکنندگان بلوک نیاز به دسترسی به داده‌های حالت کامل دارند، سایر گره‌ها می‌توانند بدون پایگاه داده حالت محلی بلوک‌ها را تأیید کنند.
• بی‌حالتی شدید: هیچ یک از گره‌ها نیاز به دسترسی به داده‌های کامل حالت ندارند.

انقضای داده‌ها

انقضای تاریخچه

انقضای تاریخچه به کلاینت‌هایی اشاره دارد که داده‌های قدیمی‌تر که بعید است نیاز شود را حذف می‌کند، بنابراین آنها فقط مقدار کوچکی از داده‌های قبلی را ذخیره می‌کنند، داده‌های قدیمی‌تر را با رسیدن داده‌های جدید حذف می‌کنند. کلاینت‌ها به دو دلیل نیاز به داده‌های قبلی دارند: همگام‌سازی و پردازش درخواست‌های داده. در ابتدا، کلاینت‌ها مجبور بودند از بلوک ایجاد همگام‌سازی کنند، تأیید کنند که هر بلوک متوالی تا سر زنجیره صحیح است. امروزه، کلاینت‌ها از "نقطه‌های بررسی ضعیف" برای بوت‌استرپ کردن راه خود به سر زنجیره استفاده می‌کنند. این نقاط بررسی نقاط شروع قابل اعتمادی هستند، مانند داشتن یک بلوک ایجاد که به‌جای زمان آغازین اتریوم، نزدیکتر به زمان حال است. این یعنی کلاینت‌ها می‌توانند تمام اطلاعات را قبل از جدیدترین نقطه بررسی ضعیف حذف کنند، بدون اینکه توانایی همگام‌سازی تا سر زنجیره از دست برود. کلاینت‌ها در حال حاضر درخواست‌ها (که از طریق JSON-RPC می‌رسند) برای داده‌های قبلی را با گرفتن آنها از پایگاه‌های داده محلی خود پردازش می‌کنند. با این حال، اگر داده‌های درخواست‌شده حذف شده باشد، با انقضای تاریخچه این کار ممکن نخواهد بود. جهت پردازش داده‌های قبلی، یک سری راهکارهای خلاقانه مورد نیاز است.

یک گزینه این است که کلاینت‌های داده‌های قبلی را با استفاده از راهکاریی مانند «شبکه پورتال» درخواست کنند. «شبکه پورتال» یک شبکه همتابه همتای درحال توسعه برای پردازش داده‌های قدیمی است که هر گره مقدار کوچکی از تاریخچه اتریوم را ذخیره می‌کند، به‌طوری که کل تاریخچه در سراسر شبکه به صورت توزیع‌شده وجود دارد. درخواست‌ها با جستجوی همتاهایی که داده‌های مربوطه را ذخیره می‌کنند پردازش می‌شود، و داده‌ها را از آنها درخواست می‌کند. یا درعوض، از آنجایی که این برنامه‌ها هستند که معمولاً نیاز به دسترسی به داده‌های قبلی دارند، مسئولیت ذخیره آنها را می‌توان به آنها داد. ممکن است به اندازه کافی بازیگرهای نوع‌دوست نیز در محیط اتریوم وجود داشته باشند که خواهان نگهداری آرشیوهای قدیمی باشند. می‌تواند یک DAO باشد که برای مدیریت فضای ذخیره‌سازی داده‌های قبلی راه‌اندازی می‌شود، یا در حالت ایده‌آل ترکیبی از همه این گزینه‌ها باشد. این ارائه‌دهندگان می‌توانند داده‌ها را به روش‌های بسیاری، از جمله تورنت، FTP‏، Filecoin یا IPFS پردازش کنند.

انقضای تاریخچه به‌نحوی بحث‌انگیز است، زیرا تاکنون اتریوم همیشه به‌طور ضمنی دسترسی به داده‌های قبلی را ضمانت کرده است. همگام‌سازی کامل از بلوک پیدایش همیشه به‌عنوان استاندارد ممکن بوده است، حتی اگر متکی به بازسازی برخی از داده‌های قدیمی‌تر اسنپ‌شات‌ها باشد. انقضای تاریخچه این مسئولیت‌پذیری برای این تضمین را به خارج از پروتکل اصلی اتریوم منتقل می‌کند. اگر سازمان‌های متمرکز در نهایت برای ارائه داده‌های قبلی دخیل شوند، خطرات سانسور شدن جدیدی ممکن است پدید آید.

EIP-4444 درحال حاضر آماده عرضه نیست، اما تحت بحث و بررسی فعال است. جالب است که چالش‌های EIP-4444 زیاد جنبه فنی ندارد، اما اکثراً مربوط به مسائل مدیریت جامعه اتریوم است. به منظور عرضه آن، نه تنها نیاز به پذیرش جامعه اتریوم است، بلکه باید تعهداتی برای ذخیره‌سازی و پردازش داده‌های قبلی از نهادهای مورد اعتماد وجود داشته باشد.

این ارتقا اصولاً نحوه مدیریت داده‌های حالت توسط گره‌های اتریوم را تغییر نمی‌دهد، بلکه فقط نحوه دسترسی به داده‌های قبلی را تغییر می‌دهد.

انقضای حالت

انقضای حالت به حذف حالت از گره‌های منفرد اشاره دارد، درصورتی که اخیراً مورد دسترس قرار گرفته نشده باشند. برای اجرایی کردن آن چندین راه وجود دارد:

• انقضا با اجاره: مطالبه «اجاره» از حساب‌ها و انقضای آنها زمانی‌که اجاره به صفر می‌رسد
• انقضا با زمان: غیرفعال کردن حساب درصورتی‌که خواندن/نوشتن داده‌ها در آن حساب برای مدت زمان خاصی وجود نداشته باشد

انقضا با اجاره می‌تواند به‌صورت مطالبه اجاره مستقیم از حساب‌ها برای نگه داشتن آنها در پایگاه داده حالت فعال باشد. انقضا با زمان می‌تواند شمارش معکوس از آخرین تعامل حساب یا انقضای دوره‌ای تمام حساب‌ها باشد. همچنین مکانیزمی‌هایی می‌تواند وجود داشته باشد که عناصر هر دو مدل برپایه زمان و اجاره را ترکیب کند، برای مثال اگر حساب‌های فردی قبل از انقضای زمانی هزینه اندکی بپردازند، حالت فعال آنها ادامه یابد. در انقضای حالت، باید توجه داشت که حالت فعال حذف‌نشده است، فقط جدا از حالت فعال ذخیره می‌شود. حالت غیرفعال را می‌توان به حالت فعال بازیابی کرد.

نحوه کار آن احتمالاً این طور خواهد بود که یک درخت حالت برای دوره‌های زمانی خاصی وجود داشته باشد (شاید حدود 1 سال). هر زمانی که یک دوره جدید شروع شود، یک درخت حالت جدید نیز ایجاد می‌شود. فقط درخت حالت کنونی قابل اصلاح است، مابقی درخت‌ها قابل تغییر نیستند. از گره‌های اتریوم فقط انتظار می‌رود که درخت حالت کنونی و درخت حالت اخیر را نگهداری کند. این کار به روشی نیاز دارد که طی آن یک آدرس با دوره‌ای که در آن موجود می‌باشد برچسب زمانی زده شود. چندین روش ممکن(opens in a new tab) برای انجام این کار وجود دارد، اما بهترین گزینه افزایش طول آدرس‌ها(opens in a new tab) برای تطبیق با اطلاعات اضافی است و مزیت آدرس‌های طولانی‌تر امن‌تر بودن آنها است. مورد «نقشه راه» که این کار را انجام می‌دهد گسترش فضای آدرس(opens in a new tab) گفته می‌شود.

مشابه انقضای تاریخچه، براساس انقضای حالت، مسئولیت ذخیره‌سازی داده‌های حالت از کاربران فردی برداشته می‌شود و به نهادهای دیگر از جمله ارائه‌دهندگان متمرکز، اعضای جامعه نوع‌دوست یا راهکارهای غیرمتمرکز مدرن‌تری نظیر «شبکه پورتال» محول می‌شود.

انقضای وضعیت هنوز در مرحله تحقیقاتی است و هنوز آماده عرضه نیست. انقضای حال ممکن است پس از انقضای تاریخچه و کلاینت‌های بی‌حالت روی دهد، زیرا آن ارتقاها حالت با اندازه بزرگ را برای اکثر اعتبارسنج‌ها به‌آسانی ممکن می‌سازد.

بی‌وضعیتی

بی‌حالتی تاحدی یک نام‌گذاری اشتباه است، زیرا به معنی مفهوم حذف شدن «حالت» نیست، بلکه شامل تغییراتی در نحوه مدیریت داده‌های حالت توسط گره‌های اتریوم می‌شود. «بی‌حالتی» خودش بر دو نوع خاص است: بی‌حالتی ضعیف و بی‌حالتی قوی. بی‌حالتی ضعیف با محول کردن مسئولیت ذخیره‌سازی حالت به چندین گره آنها را بی‌حالت می‌کند. بی‌حالتی قوی نیاز گره‌ها به ذخیره‌سازی داده‌های حالت کامل را کلاً رفع می‌کند. هر دو بی‌حالتی ضعیف و قوی دارای مزایای زیر برای اعتبارسنج‌های عادی هستند:

• همگام‌سازی تقریباً فوری
• توانایی اعتبارسنجی بدون نظم بلوک‌ها
• گره‌ها بتوانند با الزامات سخت‌افزاری خیلی پایین اجرا شوند (برای مثال در تلفن‌ها)
• گره‌ها بتوانند روی هارد دیسک‌های ارزان اجرا شوند، زیرا نیازی به خواندن/نوشتن روی دیسک وجود ندارد
• سازگار بودن با ارتقاهای آینده رمزنگاری اتریوم

بی‌حالتی ضعیف

بی‌حالتی ضعیف شامل تغییرات در نحوه تأیید تغییرات حالت توسط گره‌های اتریوم نیست، اما این مسئله نیاز به ذخیره‌سازی حالت را در تمام گره‌های شبکه رفع نمی‌کند. درعوض، بی‌حالتی ضعیف مسئولیت ذخیره‌سازی حالت را به پیشنهاددهندگان بلوک محول می‌کند، درحالی که سایر گره‌های شبکه بدون ذخیره‌سازی داده‌های حالت کامل، بلوک‌ها را تأیید می‌کنند.

در بی‌حالتی ضعیف، بلوک‌های پیشنهاددهنده نیاز به دسترسی داده‌های حالت کامل دارند، اما بلوک‌های تأییدکننده به داده‌های حالت نیاز ندارند

برای این رویداد، درخت‌های ورکل باید از قبل در کلاینت‌های اتریوم پیاده‌سازی شده باشند. درخت‌های ورکل یک ساختار داده جایگزین برای ذخیره‌سازی داده‌های حالت اتریوم است که اجازه می‌دهد «شاهدهای»‌ کوچک با اندازه ثابت در داده‌ها بین همتاها رد و بدل شود و برای تأیید بلوک‌ها به‌جای تأیید از طریق پایگاه‌های داده محلی استفاده شود. تفکیک پیشنهاددهنده-سازنده نیز لازم است، زیرا این کار اجازه می‌دهد سازندگان بلوک گره‌های خاص با سخت‌افزار قوی‌تر باشند و آنها گره‌هایی هستند که نیاز به دسترسی به داده‌های حالت کامل دارند.

پیشنهاددهنده‌های بلوک از داده‌های حالت برای ایجاد «شاهدها» استفاده می‌کنند - حداقل مجموعه دادهایی که مقادیر حالت درحال تغییر توسط تراکنش‌ها در یک بلوک را اثبات می‌کند. سایر اعتبارسنج‌ها دربردارنده حالت نمی‌باشند، آنها صرفاً ریشه حالت را ذخیره می‌کنند (هش کل حالت). آنها یک بلوک و یک شاهد دریافت می‌کنند و از آنها برای به‌روزرسانی ریشه حالت خود استفاده می‌کنند. این کار گره اعتبارسنجی را به‌شدت سبک می‌کند.

بی‌حالتی ضعیف یک حالت پیشرفته تحقیقاتی است، اما متکی به پیاده‌سازی تفکیک پیشنهاددهنده-سازنده و درخت‌های ورکل است تا بتوان شاهدهای کوچک را بین همتایان رد و بدل کرد. به‌عبارتی بی‌حالتی ضعیف احتمالاً چند سال از «شبکه اصلی» فاصله دارد.

بی‌حالتی قوی

بی‌حالتی قوی نیاز به ذخیره‌سازی داده‌های حالت را رفع می‌کند. درعوض، تراکنش‌ها با شاهدهایی ارسال می‌شوند که می‌توان آنها را با ایجادکننده‌های بلوک گردآوری کرد. از این رو، ایجادکننده‌های بلوک درقبال ذخیره‌سازی آن حالتی که برای ایجاد شاهدهای حساب‌های مربوطه مورد نیاز است مسئول هستند. مسئولیت حالت تقربیاً به‌طور کل به کاربران انتقال داده شده است، زیرا آنها شاهدها و «لیست‌های دسترسی»‌ را برای اعلام حساب‌ها و کلیدهای ذخیره‌سازی ارسال می‌کنند که با آنها تعامل دارند. این کار گره‌های بسیار سبک را ممکن خواهد کرد، اما ریسک‌هایی وجود دارد، از جمله اینکه تعامل با قراردادهای هوشمند را مشکل‌تر می‌سازد.

محققین بی‌حالتی قوی را مورد تحقیق قرار داده‌اند، اما انتظار نمی‌رود اکنون بخشی از نقشهٔ راه اتریوم باشد - به احتمال بیشتر بی‌حالتی ضعیف برای نیازهای مقیاس‌پذیری اتریوم کافی است.

پیشرفت فعلی

بی‌حالتی ضعیف، انقضای تاریخچه و انقضای حالت همگی در مرحله تحقیق است و انتظار می‌رود چند سال بعد عرضه شوند. هیچ تضمینی وجود ندارد که تمام این پیشنهادها پیاده‌سازی شوند، برای مثال، اگر انقضای حالت ابتدا پیاده‌سازی شود، ممکن است دیگر نیازی به پیاده‌سازی انقضای تاریخچه نباشد. همچنین موارد دیگری از نقشه راه وجود دارد، از جمله درخت‌های ورکل و تفکیک پیشنهاددهنده-سازنده که باید اول تکمیل شود.

بیشتر بخوانید

• بی‌حالتی ویتالیک AMA(opens in a new tab)
• نظریه مدیریت اندازه حالت(opens in a new tab)
• وابستگی حالت کمینه‌سازی-بازیابی-تضاد(opens in a new tab)
• مسیرها به بی‌حالتی و انقضای حالت(opens in a new tab)
• خصوصیات EIP-4444(opens in a new tab)
• Alex Stokes پیرامون EIP-4444(opens in a new tab)
• چرا بی‌حالت شدن آنقدر اهمیت دارد(opens in a new tab)
• یادداشت‌های اصلی مفهوم کلاینت بی‌حالت(opens in a new tab)
• اطلاعات بیشتر درباره انقضای حالت(opens in a new tab)
• باز هم اطلاعات بیشتر درباره انقضای حالت(opens in a new tab)