پروپوزال بهبود اتریوم چیست؟ آشنایی با مفهوم، انواع و چرخه تایید EIP

در این مقاله از کیف پول من، ساختار خشک و فنی توسعه‌دهندگان را کنار می‌گذاریم تا به شکلی شفاف و کاربردی، مکانیزم ارتقای این بلاک‌چین اتریوم را بررسی کنیم. با مطالعه این مطلب، قدم‌به‌قدم متوجه خواهید شد که پروپوزال بهبود اتریوم (EIP) دقیقا چیست، چگونه از یک پیش‌نویس خام به یک آپدیت تاریخ‌ساز تبدیل می‌شود و از همه مهم‌تر، تغییرات کلیدی اخیر چگونه قرار است توان عملیاتی شبکه (Scalability) را افزایش داده و دغدغه همیشگی کارمزدها را برای شما برطرف کنند.

پروپوزال بهبود اتریوم (EIP) چیست؟

شبکه‌ی اتریوم متعلق به یک فرد یا شرکت خاص نیست، بلکه یک سیستم غیرمتمرکز است. برای ایجاد هر تغییری در این شبکه‌ی بزرگ، به یک روش استاندارد نیاز داریم. پروپوزال بهبود اتریوم یا همان EIP (مخفف Ethereum Improvement Proposal) در واقع یک سند رسمی است که پیشنهادهایی برای بهبود، تغییر یا افزودن ویژگی‌های جدید به شبکه‌ی اتریوم را ارائه می‌دهد.

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

چرا شبکه اتریوم به پروپوزال‌های بهبود (EIP) نیاز دارد؟

از آنجا که اتریوم یک پروژه‌ی متن‌باز (کدهایی قابل مشاهده و ویرایش برای همه) است، هیچ مدیرعامل یا هیئت مدیره‌ای وجود ندارد که پشت درهای بسته تصمیم‌گیری کند و دستور تغییرات را صادر کند. بنابراین، برای اینکه شبکه بتواند رشد کند و با نیازهای روز تطبیق یابد، به پروپوزال‌های بهبود نیاز داریم. اهمیت و ضرورت این پروپوزال‌ها شامل موارد زیر است:

• ایجاد یک زبان مشترک: توسعه‌دهندگان از سراسر دنیا می‌توانند ایده‌های خود را به شکلی ساختاریافته و استاندارد مطرح کنند تا برای همه قابل فهم باشد.
• رفع باگ‌ها و مشکلات فنی: اگر خطایی در سیستم وجود داشته باشد یا امنیت شبکه به خطر بیفتد، از طریق یک EIP می‌توان راه حلی سریع و اصولی برای آن ارائه داد.
• ارتقای مستمر شبکه: تغییرات بزرگی مانند کاهش کارمزدها، افزایش سرعت، یا تغییر الگوریتم اجماع (روش توافق کامپیوترهای شبکه برای تایید تراکنش‌ها بدون نیاز به واسطه) تنها از طریق همین پیشنهادها بررسی و در نهایت اجرا می‌شوند.

بدون وجود این سندهای پیشنهادی، شبکه‌ی اتریوم دچار هرج و مرج می‌شد و هیچ مسیر روشنی برای پیشرفت و هماهنگی میان اعضای بی‌شمار جامعه‌ی آن وجود نداشت.

رفع یک ابهام رایج: تفاوت EIP و ERC در چیست؟

بسیاری از کاربران تازه‌کار، اصطلاحات EIP و ERC را با هم اشتباه می‌گیرند یا فکر می‌کنند این دو کاملا از هم جدا هستند. برای درک تفاوت این دو، باید بدانید که ERC (درخواست نظر اتریوم) در واقع یک زیرمجموعه از EIP است.

برای درک بهتر، این‌طور تصور کنید که EIP نام یک کتابخانه‌ی بزرگ از تمام پیشنهادها است. برخی از این پیشنهادها مربوط به هسته‌ی اصلی و زیرساخت شبکه‌ی اتریوم هستند، در حالی که برخی دیگر فقط قوانینی برای ساخت برنامه‌ها و توکن‌ها ارائه می‌دهند. به این پیشنهادهای دسته‌ی دوم که مربوط به لایه‌ی برنامه‌های کاربردی هستند، ERC می‌گویند.

به عنوان مثال، وقتی یک توسعه‌دهنده می‌خواهد یک استاندارد جدید برای ساخت توکن یا قرارداد هوشمند (کدهای برنامه‌نویسی خودکاری که روی بلاک‌چین اجرا می‌شوند و نیازی به واسطه ندارند) معرفی کند، یک ERC ارائه می‌دهد. استاندارد معروف ERC-20 که برای ساخت بیشتر توکن‌های اتریوم استفاده می‌شود، در ابتدا تنها یک پروپوزال بهبود یا همان EIP بوده است. بنابراین، می‌توانیم بگوییم هر ERC قطعا یک EIP است، اما هر EIP لزوما یک ERC نیست.

چه کسانی در ارائه و تایید پروپوزال‌های اتریوم نقش دارند؟

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

• نویسندگان (Authors): هر کسی در دنیا، چه یک برنامه‌نویس حرفه‌ای باشد و چه یک کاربر پیگیر با یک ایده‌ی درخشان، می‌تواند یک پروپوزال بنویسد. البته این ایده باید از نظر فنی دقیق و منطبق بر استانداردهای نگارشی شبکه باشد.
• ویرایشگران (EIP Editors): گروهی از متخصصان فنی و مورد اعتماد جامعه‌ی اتریوم هستند که پیشنهادها را دریافت می‌کنند. وظیفه‌ی آن‌ها این نیست که ایده را تایید یا رد کنند؛ بلکه فقط بررسی می‌کنند که پروپوزال از نظر فنی سالم باشد، با فرمت استاندارد نوشته شده باشد و با سایر قوانین مغایرت نداشته باشد.
• توسعه‌دهندگان هسته (Core Developers): این افراد برنامه‌نویسانی هستند که کدهای اصلی شبکه‌ی اتریوم را می‌نویسند و مدیریت می‌کنند. آن‌ها پروپوزال‌های بررسی شده را ارزیابی کرده و در صورت توافق، کدهای لازم برای اجرای آن‌ها را به برنامه‌ی اصلی اضافه می‌کنند.
• جامعه‌ی کاربران و اعتبارسنج‌ها: در نهایت، تصمیم‌گیرنده‌ی نهایی خود شبکه است. اعتبارسنج‌ها (نودها یا کامپیوترهایی که تراکنش‌ها را تایید و امنیت شبکه را تامین می‌کنند) باید نرم‌افزارهای خود را با آپدیت جدید به‌روزرسانی کنند. اگر جامعه‌ی اتریوم یک تغییر را نپذیرد و نرم‌افزار خود را آپدیت نکند، آن پروپوزال هرگز در شبکه‌ی اصلی و واقعی اجرا نخواهد شد.

دسته‌بندی پروپوزال‌های شبکه؛ آشنایی با انواع EIP

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

پروپوزال‌های مسیر استاندارد (Standard Track EIPs) و زیرمجموعه‌های آن

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

• هسته (Core): این پروپوزال‌ها مربوط به عمیق‌ترین و حساس‌ترین بخش‌های شبکه هستند. تغییر در قوانین ایجاد بلاک‌های جدید یا تغییر در مکانیزم پاداش‌دهی به تایید کنندگان شبکه، در این بخش قرار می‌گیرد.
• شبکه‌سازی (Networking): این دسته به نحوه‌ی ارتباط نودها (نودها یا Nodes: کامپیوترهای متصل به شبکه که اطلاعات را ذخیره، پردازش و تایید می‌کنند) با یکدیگر می‌پردازد. هر تغییری که باعث شود اطلاعات بین کامپیوترهای شبکه سریع‌تر و امن‌تر منتقل شود، یک پروپوزال شبکه‌سازی است.
• رابط کاربری (Interface): این پیشنهادها روی روش ارتباط برنامه‌های بیرونی با شبکه‌ی اتریوم تمرکز دارند. به زبان ساده، قوانینی هستند که تعیین می‌کنند کلاینت‌ها (نرم‌افزارهایی که امکان اتصال کاربران به بلاک‌چین را فراهم می‌کنند) چگونه باید اطلاعات را از شبکه بخوانند یا به آن ارسال کنند.
• درخواست نظر اتریوم (ERC): همان‌طور که در بخش قبل اشاره کردیم، این دسته مربوط به استانداردهای لایه‌ی برنامه‌های کاربردی است. هر قانونی که برای ساخت توکن‌های جدید، قراردادهای هوشمند یا کیف پول‌ها نیاز باشد، در قالب یک ERC ارائه می‌شود.

پروپوزال‌های متا یا فرآیندی (Meta EIPs)

کلمه‌ی متا به معنای فراتر است. پروپوزال‌های متا مستقیما کدهای شبکه‌ی اتریوم را تغییر نمی‌دهند، بلکه فرآیندها و قوانین پیرامون آن را هدف می‌گیرند.

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

پروپوزال‌های اطلاعاتی (Informational EIPs)

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

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

جدول مقایسه سریع انواع EIP و کاربرد هر کدام

برای اینکه تفاوت این سه دسته بهتر در ذهن شما بماند، نگاهی به جدول زیر بیندازید. این جدول به عنوان یک نقشه‌ی راه سریع، به شما کمک می‌کند کاربرد هر پروپوزال را به راحتی مرور کنید:

نوع پروپوزال	هدف و کاربرد اصلی	مثال یا استعاره ملموس
مسیر استاندارد (Standard)	تغییر در کدهای اصلی، قوانین شبکه و استانداردهای برنامه‌نویسی	تغییر موتور ماشین یا ساخت یک اتوبان جدید در شهر
متا یا فرآیندی (Meta)	تغییر در فرآیندها، قوانین تصمیم‌گیری و نحوه‌ی ثبت پیشنهادها	تغییر قوانین برگزاری جلسات شهرداری و نحوه رای‌گیری
اطلاعاتی (Informational)	ارائه‌ی راهنما، توصیه‌های امنیتی و اطلاعات مفید بدون ایجاد الزام	چاپ یک دفترچه راهنمای رانندگی ایمن برای شهروندان

چرخه‌ی حیات یک پروپوزال؛ مراحل پردازش و تایید EIP چگونه است؟

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

گام‌به‌گام از ایده‌ی خام تا اجرای نهایی در شبکه‌ی اتریوم

برای اینکه یک پیشنهاد بتواند وارد سیستم شود، باید یک مسیر مشخص و استاندارد را طی کند. این مسیر شامل مراحل زیر است:

• شکل‌گیری ایده و بحث اولیه: همه‌چیز از یک ایده‌ی خام در انجمن‌های گفتگوی اتریوم (مانند فروم‌های تخصصی توسعه‌دهندگان) شروع می‌شود. نویسنده ایده‌ی خود را مطرح می‌کند تا بازخورد جامعه را دریافت کند.
• نوشتن پیش‌نویس: اگر ایده با استقبال روبرو شد، نویسنده باید آن را در قالب یک سند رسمی و استاندارد بنویسد. این سند باید شامل توضیحات فنی دقیق، دلیل نیاز به این تغییر و مشکلات احتمالی باشد.
• بررسی توسط ویرایشگران: پیش‌نویس برای ویرایشگران ارسال می‌شود. آن‌ها فقط بررسی می‌کنند که آیا پروپوزال از نظر نگارشی و فرمت استاندارد است یا خیر و به محتوای فنی آن کاری ندارند.
• آزمایش و رفع ایرادات: قبل از اینکه هر تغییری وارد شبکه‌ی اصلی شود، ابتدا روی شبکه‌های آزمایشی یا تست‌نت (Testnet: محیطی شبیه‌سازی شده برای تست برنامه‌ها و کدها بدون خطر از دست رفتن پول واقعی) اجرا می‌شود تا باگ‌ها و مشکلات فنی آن مشخص و برطرف شود.
• اجرای نهایی (به‌روزرسانی شبکه): وقتی همه‌ی متخصصان روی کدها توافق کردند و هیچ مشکلی در تست‌ها دیده نشد، کد جدید آماده‌ی اجرا می‌شود. نودهای شبکه نرم‌افزارهای خود را آپدیت می‌کنند که به این فرآیند اصطلاحا هارد فورک (Hard Fork: یک ارتقای اساسی در قوانین بلاک‌چین که نیاز به به‌روزرسانی اجباری همه‌ی اعضا دارد) می‌گویند.

مرور وضعیت‌های مختلف یک پروپوزال

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

• ایده (Idea): مرحله‌ی غیر رسمی که پیشنهاد هنوز در حد یک بحث در انجمن‌ها است و وارد مسیر رسمی نشده است.
• پیش‌نویس (Draft): اولین مرحله‌ی رسمی است. پروپوزال قالب استاندارد را رعایت کرده و توسط ویرایشگران پذیرفته شده است، اما هنوز جای کار و تغییرات فنی زیادی دارد.
• در حال بررسی (Review): نویسنده‌ی پروپوزال معتقد است که کار نوشتن و طراحی تمام شده است و از سایر متخصصان می‌خواهد که کدهای او را به دقت نقد و بررسی کنند.
• فراخوان نهایی (Last Call): این یک دوره‌ی زمانی محدود (معمولا 14 روزه) است. پروپوزال تقریبا آماده است و به جامعه‌ی اتریوم فرصت داده می‌شود تا برای آخرین بار ایرادات احتمالی را گزارش دهند. اگر مشکل مهمی پیدا شود، پروپوزال دوباره به وضعیت در حال بررسی برمی‌گردد.
• نهایی‌شده (Final): پیشنهاد از تمامی فیلترها با موفقیت عبور کرده است. کدهای آن استاندارد و کامل هستند و آماده‌ی پیاده‌سازی در شبکه‌ی اتریوم خواهند بود.
• راکد (Stagnant): اگر یک پروپوزال در وضعیت پیش‌نویس یا بررسی باشد و به مدت 6 ماه هیچ فعالیتی (تغییر یا بحث) روی آن انجام نشود، این برچسب را می‌گیرد. البته نویسنده همیشه می‌تواند آن را دوباره به جریان بیندازد.
• پس‌گرفته‌شده (Withdrawn): نویسنده بنا به هر دلیلی تصمیم می‌گیرد از ادامه‌ی پیگیری ایده‌ی خود منصرف شود. این وضعیت پایان قطعی راه یک پروپوزال است.
• پویا یا زنده (Living): برخی پروپوزال‌ها هرگز وضعیت نهایی به خود نمی‌گیرند، چون ماهیت آن‌ها طوری است که باید مدام به‌روزرسانی شوند. به عنوان مثال، پروپوزال شماره یک (EIP-1) که راهنمای اصلی نوشتن خود پروپوزال‌ها است، همیشه در وضعیت پویا قرار دارد تا در صورت نیاز قوانین جدیدی به آن اضافه شود.

نگاهی به تاریخ‌سازترین پروپوزال‌های بهبود اتریوم

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

مروری بر معروف‌ترین EIPهایی که اتریوم را متحول کردند

بیایید به سراغ چند نمونه از معروف‌ترین طرح‌های بهبود برویم که هر کدام یک نقطه‌ی عطف در تاریخ این شبکه به شمار می‌آیند. آشنایی با این موارد به شما نشان می‌دهد که اتریوم چگونه توانسته است پویایی خود را حفظ کند:

• پروپوزال EIP-20 (تولد استاندارد ERC-20): در روزهای اول، هر کسی که می‌خواست روی شبکه‌ی اتریوم یک ارز دیجیتال جدید بسازد، باید قوانین خودش را از صفر می‌نوشت. این پروپوزال یک قالب استاندارد برای ساخت توکن‌های قابل تعویض (Fungible Tokens: توکن‌هایی که ارزش همه‌ی آن‌ها با هم برابر است، مانند اسکناس‌های ده‌هزار تومانی) ایجاد کرد. با این استاندارد، ساخت توکن بسیار ساده شد و امروزه هزاران توکنی که در کیف پول خود دارید، از همین قانون پیروی می‌کنند.
• پروپوزال EIP-721 (انقلاب توکن‌های غیرمثلی یا NFT): برخلاف توکن‌های معمولی، گاهی اوقات نیاز داریم مالکیت یک دارایی کاملا منحصربه‌فرد مانند یک اثر هنری دیجیتال یا سند یک خانه‌ی مجازی را ثبت کنیم. این پروپوزال استاندارد جدیدی را معرفی کرد که امکان ساخت توکن‌های غیرمثلی (NFT: دارایی‌های دیجیتال بی‌همتا که قابل کپی‌برداری نیستند) را فراهم کرد و دنیای هنر دیجیتال و بازی‌های بلاک‌چینی را به طور کامل متحول ساخت.
• پروپوزال EIP-1559 (تحول در سیستم کارمزدها): تا قبل از این آپدیت، سیستم پرداخت کارمزد در شبکه‌ی اتریوم شبیه به یک مزایده‌ی کورکورانه بود. هر کسی پول بیشتری می‌داد، تراکنش او زودتر تایید می‌شد و این موضوع باعث می‌شد کارمزدها به شدت غیرقابل پیش‌بینی و گران باشند. این پروپوزال مکانیزم را تغییر داد؛ یک کارمزد پایه‌ی مشخص برای همه تعیین کرد تا هزینه‌ها قابل پیش‌بینی شوند. همچنین قابلیت توکن‌سوزی (Token Burning: فرآیند خارج کردن دائمی بخشی از ارزها از چرخه‌ی بازار برای کاهش تورم) را معرفی کرد تا با سوزاندن بخشی از کارمزدها، ارز دیجیتال اتریوم به یک دارایی کمیاب‌تر و ارزشمندتر تبدیل شود.
• پروپوزال EIP-3675 (ارتقای بزرگ یا The Merge): این پروپوزال یکی از حساس‌ترین تغییرات تاریخ اتریوم بود. با اجرای این طرح، شبکه‌ی اتریوم روش تایید تراکنش‌های خود را از الگوریتم اثبات کار (Proof of Work: روشی که در آن از دستگاه‌های پرمصرف ماینر برای تایید تراکنش‌ها استفاده می‌شود) به الگوریتم اثبات سهام (Proof of Stake: تایید تراکنش‌ها با قفل کردن دارایی در شبکه و بدون نیاز به مصرف برق) تغییر داد. این کار درست شبیه این بود که موتور یک ماشین در حال حرکت را از بنزینی به برقی تغییر دهند تا مصرف انرژی شبکه‌ی اتریوم بیش از 99 درصد کاهش یابد!

بررسی پروپوزال EIP-4844؛ گامی بزرگ برای افزایش توان عملیاتی

یکی از بزرگترین دغدغه‌های کاربران در شبکه‌ی اتریوم، کندی تراکنش‌ها و هزینه‌ی بالای کارمزدها در زمان شلوغی بازار است. توسعه‌دهندگان برای حل این مشکل، طرح‌های مختلفی را پیشنهاد داده‌اند که یکی از مهم‌ترین آن‌ها پروپوزال EIP-4844 است. این آپدیت که سر و صدای زیادی در دنیای رمزارز به پا کرده است، به عنوان یک نقطه‌ی عطف برای مقیاس‌پذیری (Scalability: توانایی شبکه برای پردازش تعداد زیادی تراکنش به صورت همزمان بدون افت سرعت) شناخته می‌شود. در ادامه این پروپوزال را به ساده‌ترین شکل ممکن بررسی می‌کنیم.

پروپوزال EIP-4844 چیست و چه هدفی را دنبال می‌کند؟

برای درک این پروپوزال، ابتدا باید با اصطلاح پروتو-دنک شاردینگ (Proto-Danksharding) آشنا شویم. کلمه‌ی شاردینگ در علوم کامپیوتر به معنای تکه‌تکه کردن یک پایگاه داده‌ی بزرگ به بخش‌های کوچک‌تر است تا پردازش اطلاعات سریع‌تر انجام شود. اگر اتریوم را یک اتوبان شلوغ در نظر بگیریم، شاردینگ به معنای اضافه کردن باندهای جدید به این اتوبان است.

پروپوزال EIP-4844 در واقع پیش‌نیاز و قدم اول برای رسیدن به این اتوبان چند بانده است. هدف اصلی این پیشنهاد، معرفی یک نوع جدید از تراکنش‌ها است که می‌توانند بسته‌های بزرگی از داده‌ها را با خود حمل کنند. به این بسته‌های داده، بلاب (Blob: مخفف عبارت Binary Large Object به معنای شیء بزرگ اطلاعاتی) می‌گویند. بلاب‌ها به شبکه‌ی اتریوم اجازه می‌دهند حجم بسیار بیشتری از اطلاعات را بدون اینکه به هسته‌ی اصلی شبکه فشار بیاورند، جابه‌جا کنند.

راهکار EIP-4844 چگونه به کاهش کارمزدها و راحتی کاربران کمک می‌کند؟

برای اینکه بفهمیم این پیشنهاد چگونه هزینه‌ی شما را کاهش می‌دهد، باید به شبکه‌های لایه‌ی دوم (Layer 2: شبکه‌هایی که روی اتریوم ساخته می‌شوند تا تراکنش‌ها را سریع‌تر و ارزان‌تر پردازش کنند و سپس نتیجه‌ی نهایی را به شبکه‌ی اصلی بفرستند) توجه کنیم.

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

بررسی چالش‌ها و موانع پیش‌روی پیاده‌سازی EIP-4844

هیچ تغییر بزرگی بدون چالش نیست. اضافه‌کردن این ویژگی به شبکه‌ی اتریوم نیازمند تغییرات عمیقی در زیرساخت برنامه‌نویسی آن بود. مهم‌ترین چالش‌های این مسیر عبارتند از:

• فشار روی نودها: با اضافه شدن بلاب‌ها، حجم داده‌هایی که کامپیوترهای شبکه (نودها) باید دانلود و بررسی کنند در کوتاه‌مدت افزایش می‌یابد. این موضوع نیازمند اینترنت قوی‌تر و سخت‌افزار بهتری برای این سیستم‌ها است.
• پیچیدگی هماهنگی فنی: شبکه‌ی اتریوم از دو بخش اصلی برای پردازش و تایید تراکنش‌ها تشکیل شده است. پیاده‌سازی پروپوزال 4844 نیازمند هماهنگی بی‌نقص بین توسعه‌دهندگان بخش‌های مختلف بود تا شبکه‌ی میلیارد دلاری اتریوم در حین آپدیت دچار اختلال یا قطعی نشود.

آیا EIP-4844 به تنهایی یک راه‌حل نهایی و کامل برای اتریوم است؟

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

سرنوشت داده‌ها پس از اجرای EIP-4844

همان‌طور که گفتیم، بلاب‌ها شبیه به وایت‌بردی هستند که اطلاعات روی آن‌ها نوشته می‌شود. اما برای اینکه فضای ذخیره‌سازی نودهای شبکه پر نشود و کامپیوترهای معمولی هم بتوانند به شبکه متصل بمانند، این اطلاعات نباید تا ابد باقی بمانند. بر اساس این پروپوزال، داده‌های درون بلاب‌ها پس از یک دوره‌ی مشخص (حدود ۱۸ تا ۳۰ روز) از روی شبکه‌ی اصلی اتریوم پاک می‌شوند.

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

آشنایی با پروپوزال EIP-4444 و تغییرات ساختاری در ذخیره‌سازی نودها

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

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

در پروپوزال EIP-4444 دقیقا چه اتفاقی رخ می‌دهد و چه مشکلی حل می‌شود؟

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

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

چالش حذف داده‌های تاریخی؛ راهکار جایگزین برای مشکل EIP-4444 چیست؟

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

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

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

نقش شبکه‌ی کوالنت (Covalent) در حفظ تاریخچه‌ی داده‌ها و همگامی با EIP-4444

یکی از مهم‌ترین پروژه‌هایی که برای حل چالش نگهداری داده‌های تاریخی به کمک شبکه‌ی اتریوم آمده، شبکه‌ی کوالنت است. کوالنت یک پروژه‌ی تخصصی برای جمع‌آوری و ایندکس کردن (Indexing: مرتب‌سازی و دسته‌بندی اطلاعات برای جستجوی سریع و راحت، درست شبیه به فهرست انتهای یک کتاب ضخیم) اطلاعات بلاک‌چینی است.

کوالنت برای همگامی با پروپوزال EIP-4444، راهکاری نوآورانه به نام ماشین زمان اتریوم را معرفی کرده است. عملکرد این شبکه در حفظ تاریخچه‌ی اتریوم را می‌توان در این مراحل خلاصه کرد:

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

منابع:

Binance

Cyfrin

Coinbase