پرج (Purge)؛ پاکسازی و سادهسازی اتریوم با کاهش حجم دادهها
ویتالیک بوترین، یکی از بنیانگذاران اتریوم، قسمت پنجم از مجموعه وبلاگ خود به نام “The Purge” را با هدف کاهش تورم دادهها و سادهسازی پروتکل اتریوم منتشر کرد.
به گزارش میهن بلاکچین، هدف Purge سادهسازی اتریوم با کاهش حجم دادهها، سادهسازی پروتکل و پرداختن به مشکلات فنی برای کارایی بهتر است.
پرج (Purge) چیست؟
پرج بر کاهش ذخیرهسازی دادههای غیرضروری و حذف ویژگیهای منسوخ برای کارآمدتر کردن اتریوم و در عین حال حفظ «دوام» بلاکچین تمرکز دارد.
Purge قرار نیست مستقیما بر هزینههای گاز اتریوم تأثیر بگذارد. با این حال، تغییرات پیشنهادی ممکن است عملکرد شبکه را افزایش داده و هزینههای عملیاتی را کاهش دهد.
کاهش فضای ذخیرهسازی برای عملکرد بهتر گره
یکی از عناصر کلیدی The Purge مقابله با موانع روزافزون گرههای جدید در هنگام پیوستن به شبکه اتریوم است که نیاز به ذخیرهسازی را افزایش میدهد.
طبق دادههای ycharts، یک گره اتریوم در حال حاضر به بیش از ۱.۱۷ ترابایت (TB) فضای ذخیرهسازی نیاز دارد که بخش عمده آن به دلیل ذخیره دادههای تاریخی است.
ابتکار Purge هدف کاهش نیازهای ذخیرهسازی کلاینت، با کاهش یا حذف نیاز هر گره برای ذخیره دائمی تمام تاریخچه را مورد بحث قرار میدهد و شاید در نهایت حتی حالت (State) نیز بتواند کاهش یابد.
۱. بی حالتی (Statelessness) و عدم معرفی انقضای حالت
در شبکه اتریوم، حالت (state) به وضعیت فعلی همه حسابها، موجودیها، کد قرارداد هوشمند و ذخیرهسازی روی بلاکچین اشاره دارد. اساسا حالت یک اسنپ شات از همه چیز در شبکه اتریوم در یک لحظه خاص است.
زمانی که تراکنشهای جدید در اتریوم انجام میشوند، آنها حالت را تغییر میدهند. برای مثال، اگر شخصی ETH ارسال کند یا با یک پروتکل دیفای تعامل داشته باشد، با بهروزرسانی موجودیها یا اصلاح دادهها در یک قرارداد هوشمند، حالت را تغییر میدهد.
هر بار که حالت تغییر می کند (به عنوان مثال، یک قرارداد جدید مستقر یا به روز میشود)، دادههای حالت جدید به طور دائم اضافه میشوند. با ایجاد قراردادها و دادههای بیشتر، وضعیت اتریوم همچنان در حال گسترش است و مدیریت و ذخیره کارآمد آن را در طول زمان سختتر می کند، زیرا در حال حاضر هیچ مکانیزمی برای حذف یا «انقضای» دادههای حالت قدیمی وجود ندارد.
در رویکرد فعلی بوترین، اتریوم قرار است به سمت عدم وجود حالت (بیحالتی) پیش برود و هرگز انقضای حالت را معرفی نمیکند. این یعنی حالت با سرعت کمتری در حال رشد بوده و احتمالاً در دهههای آینده به ۸ ترابایت نمیرسد. در این سناریو، فقط یک کلاس خاص از کاربران نیاز به حفظ حالت خواهند داشت و حتی اعتبارسنجهای اثبات سهام (PoS) نیز به حالت نیازی ندارند.
این رویکرد به کاربران این امکان را میدهد که به صورت موثر و با کاهش بار ذخیرهسازی، به فعالیتهای خود ادامه دهند. با این حال، عدم وجود حالت ممکن است موجب بروز چالشهایی در زمینه دسترسی به تاریخچه تراکنشها و اطلاعات کاربران شود.
۲. انقضای جزئی حالت (Partial State Expiry)
همان طور که گفته شد، هر داده جدیدی که به شبکه اضافه میشود، بهطور دائم در آنجا باقی میماند و باعث رشد سیستم میشود، اما بوترین به دنبال مقابله با این موضوع از طریق «انقضای جزئی حالت» است.
این ایده جدید شامل انقضای دادههای حالتی است که کمتر مورد استفاده قرار میگیرند و بعدا از طریق اثبات رمزنگاری در صورت لزوم احیا میشوند.
این رویکرد این امکان را میدهد تا بخشی از تاریخ و دادههای غیرضروری را از بین برده و فضای ذخیرهسازی را بهینهسازی کنیم. به عنوان مثال، اتریوم میتواند به تدریج دادههای قدیمی را از بلاکچین حذف کند و بدین ترتیب بار ذخیرهسازی را کاهش دهد. اما هنوز هم یک چالش باقی میماند: چگونه میتوانیم اطمینان حاصل کنیم که اطلاعات حیاتی حفظ شده و در دسترس هستند؟
برای حل این مشکل، اتریوم میتواند از راهکارهای مختلفی همچون ذخیرهسازی دادهها در سرورهای خارج از زنجیره یا استفاده از فناوریهای ذخیرهسازی توزیع شده بهره بگیرد. به این ترتیب، اتریوم میتواند در عین کاهش بار ذخیرهسازی، قابلیت دسترسی (Availability) به اطلاعات مهم را نیز حفظ کند.
۳. انقضای حالت با گسترش فضای آدرس (Address Space Expansion)
این گزینه شامل یک فرایند چندساله است که اطمینان حاصل میکند رویکرد تبدیل فرمت آدرس کار کند و برای برنامههای موجود ایمن است. در بخش، با توجه به چالشهای ناشی از گسترش فضای آدرس، باید به شیوهای طراحی شود که تمام نقاط ضعف امنیتی مرتبط با آن قابل مدیریت باشد.
یکی از مشکلات مهم در اینجا، امکان تداخل آدرسها است. در حال حاضر، برای تولید یک تداخل آدرس (Collision)، به طور تقریبی ۲ به توان ۸۰ هش لازم است که بار محاسباتی آن برای بازیگران بسیار قوی امکانپذیر بوده و با تراکم فضا به ۲ به توان ۵۰ میرسد. این تهدیدات در آینده میتواند بیشتر و بیشتر به دست افراد عادی بیفتد.
بنابراین، اتریوم باید راهکارهای امنیتی موثری را برای جلوگیری از تداخل آدرسها و حفظ ایمنی شبکه ارائه کند. این امر ممکن است شامل استفاده از الگوریتمهای جدید برای تولید آدرسها و همچنین ایجاد قوانین سختگیرانه برای کاربران باشد.
۴. انقضای حالت با کاهش فضای آدرس (Address Space Contraction)
این گزینه نیز شامل یک فرایند چندساله است که در آن تمامی خطرات امنیتی مربوط به تداخل آدرس، از جمله حالتهای بین زنجیرهای را مدیریت خواهند کرد. این سناریو به ما امکان میدهد تا بهینهسازیهای قابل توجهی انجام داد، اما هزینهها و پیچیدگیهایی را نیز به همراه خواهد داشت.
حرکت به سمت تایید بدون حالت
پست وبلاگ Purge به دنبال معرفی ارتقای ورج (The Verge) در ۲۳ اکتبر منتشر شده که برای اجرای یک گره در شبکه اتریوم ایمنتر و در دسترستر طراحی شده است.
هدف ارتقای Verge کاهش الزامات سختافزاری برای تأیید بلاک بدون ذخیره مقادیر زیادی از دادهها از طریق «تأیید بدون حالت» است.
این روش تأیید جدید میتواند «تأیید کامل زنجیره را چنان مقرون به صرفه کند که هر کیف پول موبایل، کیف پول مرورگر و حتی ساعت هوشمند» بتواند یک گره را در شبکه اجرا کند.
پاکسازی ویژگیها (Feature Cleanup)
«پاکسازی ویژگیها» در اتریوم به معنای حذف ویژگیهای قدیمی و پیچیده است که به کارایی پروتکل آسیب میزنند. این فرآیند، امنیت و سادگی شبکه را افزایش میدهد و امکان توسعه آسانتر و روانتر را برای برنامهنویسان فراهم میکند. برای نمونه، حذف کدهایی مثل SELFDESTRUCT، برخی از انواع تراکنشهای قدیمی و کدگذاریهای پیچیده مانند RLP، از جمله مراحل مهم در این تمیزکاری هستند.
مشکلاتی که پرج حل میکند
یکی از پیششرطهای کلیدی امنیت، دسترسیپذیری و بیطرفی قابلقبول، سادگی است. اگر یک پروتکل زیبا و ساده باشد، احتمال وجود اشکالات کاهش مییابد. همچنین، این امر باعث میشود که توسعهدهندگان جدید بتوانند به راحتی با هر بخشی از آن کار کنند. اگر اتریوم نخواهد به سیاهچالی از پیچیدگی فزاینده تبدیل شود، باید یکی از دو کار را انجام دهد: (i) تغییرات را متوقف کرده و پروتکل را فریز کند یا (ii) ویژگیها را حذف کرده و پیچیدگی را کاهش دهد.
هیچ راهحل بزرگی برای کاهش پیچیدگی پروتکل وجود ندارد؛ مشکل ذاتی این است که اصلاحات کوچک و متعددی وجود دارد. برای مثال، حذف کد SELFDESTRUCT یکی از مراحل عمده در این زمینه است. این کد تنها کدی بود که میتوانست در یک بلاک، تعداد نامحدودی از اسلاتهای ذخیرهسازی را اصلاح کند و به همین دلیل، نیاز به پیادهسازی پیچیدگیهای زیادی برای جلوگیری از حملات داس (DoS) وجود داشت.
نمونههایی از فرصتهای سادهسازی پروتکل
۱. انتقال از RLP به SSZ: نوعی کدگذاری است که برای اشیاء اتریوم استفاده میشود و به شدت پیچیده است. اکنون زنجیره بیکن از SSZ استفاده میکند که در بسیاری از جهات بهتر است.
۲. حذف انواع قدیمی تراکنش: تعداد زیادی نوع تراکنش وجود دارد که بسیاری از آنها میتوانند حذف شوند. یک راهحل میانه میتواند ویژگی انتزاع حساب (Abstraction) باشد که حسابهای هوشمند بتوانند کدی برای پردازش و تأیید تراکنشهای قدیمی اضافه کنند.
۳. اصلاح LOG: لاگ فیلترهای بلوم (Bloom) و منطق دیگری ایجاد میکنند که به پیچیدگی پروتکل اضافه میکند، اما در واقع توسط مشتریان استفاده نمیشود.
۴. حذف کمیتههای زنجیره بیکن: این مکانیزم برای پشتیبانی از نسخهای خاصی از شاردینگ (Sharding) اجرا شده بود، اما در حال حاضر شاردینگ از طریق L2ها و بلابها (blob) انجام میشود.
بررسی ارتباطات و پیوندها
انجام تغییرات مربوط به انقضای حالت و پاکسازی ویژگیها، یک مسیر جدید برای ارتقا و بهبود اتریوم است که به طور همزمان میتواند امنیت، عملکرد و سادگی پروتکل را افزایش دهد. این امر مستلزم یک برنامه زمانی چندساله است که در آن تصمیمات باید به دقت مورد بررسی قرار گیرند.
یکی از بزرگترین چالشها، ایجاد یک استاندارد برای انجام تغییرات غیر اضطراری با شکستن سازگاری عقبرو (Backward Compatibility) است. این امر شامل تحلیلهای دقیق و بحثهای جامع برای ارزیابی تأثیرات حذف ویژگیها بر روی برنامهها و کاربران است.
در نهایت، هدف اصلی حفظ هویت اتریوم به عنوان یک پلتفرم قابل اعتماد و کارآمد است. اگر فقط دو برنامه در کل اتریوم از یک ویژگی خاص استفاده کنند و یکی از آنها برای سالها هیچ کاربری نداشته باشد، باید به سادگی آن ویژگی را حذف کرد.
جمعبندی
آینده اتریوم به روشنی در دست تصمیمگیرندگان آن قرار دارد. با بررسی دقیق گزینهها و پیامدهای هر یک، اتریوم میتواند به سمت یک اکوسیستم پایدارتر و کارآمدتر حرکت کند. اقداماتی که امروز در این راستا انجام میشود، میتواند تأثیر عمیق و ماندگاری بر روی این پلتفرم و کاربرانش داشته باشد. در نهایت، موفقیت اتریوم به توانایی آن در تطبیق با تغییرات و نیازهای جدید بستگی دارد.