پیشنهادهای ایجاد بهبود در شبکه اتریوم / بخش دوم

27 خرداد 1401 | شبکه‌های اجتماعی

در این مقاله به بررسی روال ارزیابی و اعمال EIPها و قالب استاندارد یک EIP پرداختیم. پیشنیاز این مقاله، مقاله پیشین با عنوان «پیشنهادهای ایجاد بهبود در شبکه اتریوم / بخش اول» است.

عملکرد پروپوزال بهبود اتریوم

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

۱. مرحله اول: ارائه ایده

در مرحله اول نویسنده پروپوزال باید پیشنهاد خود را به انجمن اتریوم ارائه کند تا بازخورد لازم را بگیرد تا مشخص شود آیا می‌تواند آن را ادامه دهد یا خیر.

۲. مرحله دوم: ایجاد پیش‌نویس

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

۳. مرحله سوم: فراخوان آخر

در این مرحله پروپوزال برای ارائه آماده است و باید آن را در وب سایت پروپوزال‌های اتریوم نمایش دهند. ایده این مرحله این است که بیشترین تعداد ممکن پروپوزال را ببینند و پس از یک بازنگری کامل، نسخه کاملاً کاربردی از آن در دسترس باشد.

۴. مرحله چهارم: پذیرش

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

۵. مرحله پنجم: ارائه نهایی

در این مرحله تنها کار تصحیح غلط چاپی و نشر پروپوزال است. چند حالت هم برای پروپوزال‌ها وجود دارد که به شرح زیر هستند:

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

قالب EIP‌ها

هر پروپوزال بهبود اتریوم، یک سند فنی است و همه آن‌ها شکل به خصوصی دارند که شامل موارد زیر است:

۱. مقدمه (Preamble)

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

۲. سفارش شما (Your Order)

در این مرحله، توضیح مختصری که حداکثر ۲۰۰ کلمه است از مشکل فنی که در پروپوزال در حال بررسی است، بیان می‌شود.

۳. انگیزه (Motivation)

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

۴. مشخصات (Specification)

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

۵. توجیه (Justification)

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

۶. سازگاری وارونه (Backward compatibility)

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

در این بخش از سند پروپوزال باید مشخص شود که پیشنهاد نویسنده تا چه اندازه با ورژن‌های قدیمی سازگاری دارد. چنانچه این سازگاری کافی نباشد، پروپوزال رد خواهد شد.

۷. موارد آزمون (Test cases)

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

۸. پیاده سازی (Implementations)

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

۹. ملاحظات امنیتی (Security Considerations)

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

۱۰. معافیت از کپی رایت (Copyright exemption)

تمام پروپوزال‌ها باید عمومی باشند.

در مقاله بعدی، با تعدادی از مهمترین EIPها آشنا خواهیم شد و EIP 1559 به جزء بررسی خواهد شد.