یکی از مهمترین فرآیندهای توسعه اتریوم (ETH)، در EIP یا Ethereum Improvements Proposals اتفاق می افتد.
اینها اسناد فنی هستند که در آن جامعه توسعه اتریوم پیشنهادات بهبود خود را برای این پروژه ارائه می کند.
این ایده ای است که از تجربه بیت کوین (BTC) اتخاذ شده است، جایی که پیشنهادهای بهبود بیت کوین (BIP) وجود دارد که همین هدف را دارند و قبلاً در آکادمی آنلاین صرافی درباره آن صحبت کرده ایم.
دلیل اتخاذ این مدل سازمانی به دلیل نیاز به سطح بالایی از سازمان در جوامع توسعه غیرمتمرکز برای مدیریت و تصمیم گیری در مورد بهبودهای بعدی است که در پروژه ادغام می شود.
به این ترتیب، هر توسعهدهندهای میتواند یک پیشنهاد بهبود ارائه کند که در جامعه مورد بحث قرار گیرد و بسته به تأثیر آن، ممکن است در پروتکل اتریوم گنجانده شود یا نباشد.
برای این منظور، توسعهدهنده ایده باید پیشنهاد خود را با جزئیات توضیح دهد، استدلال کند که چرا اجرای آن در پروژه مثبت است و به وضوح قابلیت و تأثیر آن را نشان دهد.
از این رو، ایجاد این اسناد صریح است و یک هدف کاملاً مشخص و مشخص دارد:
پیشنهاد دادن آینده پروژه به جامعه و دادن فرصت به همگان برای بحث در مورد آن.
شروع پیشنهادات بهبود اتریوم یا EIP
همانطور که اشاره کردیم، ایده ایجاد Ethereum Improvements Proposals یا EIP از تجربیات اعمال شده در بیت کوین سرچشمه می گیرد.
به یاد داشته باشید که در بیت کوین، BIP ها به این منظور هستند که به جامعه اجازه دهند تا پیشرفت هایی را که می خواهند در پروتکل بیت کوین وارد کنند، به بقیه اعضا نشان دهند.
ایده BIP ها در ابتدا توسط امیر تاکی مطرح شد که پروتکل اولیه را برای ارائه آنها طراحی کرد و بیت کوین BIP-001 را ایجاد کرد.
سپس توسعه دهنده Luke dashjr، این ایده را به لطف تجربه خود در توسعه در جوامع آزاد (به ویژه تجربه خود در Gentoo GNU / Linux) بهبود بخشید و BIP-002 را ایجاد کرد.
از آن نقطه تا به امروز، BIP ها وسیله ای هستند که برای افزودن پیشرفت های جدید در بیت کوین مورد استفاده قرار گرفته اند.
این ایده به قدری موفقیت آمیز بود که در دیگر ارزهای دیجیتال تکرار شد و اتریوم از آن فرار نکرد.
اینگونه است که در ۲۷ اکتبر ۲۰۱۵، EIP-001 توسط مارتین بچ و هادسون جیمسون، دو توسعه دهنده بزرگ اتریوم ایجاد شد.
در EIP گفته شده، عنوان زیر قابل خواندن است:
هدف و رهنمودهای EIP
یعنی این اولین EIP خطوط کلی و هدفی که EIP ها در اتریوم خواهند بود را مشخص کرد.
در واقع، مقدمه او در این زمینه واضح تر نمی تواند باشد:
EIP مخفف عبارت Ethereum Improvement Proposal است. EIP یک سند طراحی است که اطلاعاتی را در اختیار جامعه اتریوم قرار می دهد یا ویژگی جدیدی را برای اتریوم یا فرآیندها یا محیط آن توصیف می کند.
EIP باید مشخصات فنی مختصری از ویژگی و توجیهی برای آن ارائه دهد.
نویسنده EIP مسئول ایجاد اجماع در جامعه و مستندسازی نظرات مخالف است.
طبقه بندی EIP
همانند BIP های بیت کوین، EIP های اتریوم به مجموعه ای از طبقه بندی ها احترام می گذارند که مشخص می کنند پیشرفت هایی که ارائه می دهند به کجا می روند.
در این حالت، طبقه بندی EIP Ethereum به سه کلاس تقسیم می شود که عبارتند از:
استاندارد EIP
این EIP ها برای توصیف تغییراتی که بیشتر یا همه پیاده سازی های اتریوم را تحت تاثیر قرار می دهند، استفاده می شوند.
به یاد داشته باشید که اتریوم یک پروتکل است و پیاده سازی رسمی آن در نرم افزار Geth ارائه شده است.
اما مانند این نرم افزار پیاده سازی های دیگری مانند آنچه در Hyperledger Besu و Parity می بینیم وجود دارد.
بهبودهایی که در یک EIP نوع استاندارد توضیح داده شده است معمولاً شامل تغییرات در پروتکل شبکه یا تغییر در قوانین اعتبارسنجی بلوک یا تراکنش است.
همچنین برای تغییرات استانداردهای برنامه پیشنهادی یا هر تغییر یا اضافهای که بر قابلیت همکاری برنامهها تأثیر میگذارد، اعمال میشود.
بنابراین، EIP از نوع استاندارد آنهایی هستند که بیشترین دامنه را در توسعه اتریوم دارند.
علاوه بر این، EIP از نوع استاندارد به زیر مجموعه های زیر تقسیم می شود:
اساسی- در این زیرمجموعه EIPهایی هستند که به دنبال بهبودهایی هستند که نیاز به تغییر اجماع در داخل اتریوم دارند.
نمونه خوبی از این EIP ها EIP-005 و EIP-0101 هستند.
با این حال، آن پیشرفتهایی که تغییرات لزوماً برای پروتکل اجماع حیاتی نیستند نیز شامل میشوند.
نمونه ای از دومی را می توان در EIP-086 و EIP-090 مشاهده کرد.
اجتماعی: این زیرمجموعه شامل بهبودهایی در اطراف devp2p (EIP-8) و پروتکل شبکه است، این شامل بهبودهایی است که برای مشخصات پروتکل gossip و ازدحام اتریوم ارائه شده است.
رابط: این زیرمجموعه شامل بهبودهایی در مشخصات و استانداردهای API / RPC مشتری اتریوم است.
علاوه بر این، تغییرات در سطح ABI و API از همان نیز گنجانده شده است.
نمونه خوبی از این EIP ها را می توان در EIP-006 مشاهده کرد. ERC استانداردها و کنوانسیون های سطح کاربرد، از جمله استانداردهای قراردادی مانند؛
استانداردهای توکن (ERC-20، ERC-721 y ERC-1155)،
ثبت نام (ERC-26، ERC-137)، طرحهای URI (ERC-67)، قالبهای کتابخانه / بسته (EIP-82)، و قالبهای کیف پول (EIP-75، EIP-85). هدف EIP
طبقه بندی دیگر EIP ها به عنوان Meta EIP شناخته می شود.
این EIP ها فرآیندی را در اطراف اتریوم توصیف می کنند یا تغییری در آن پیشنهاد می کنند.
این EIP ها به طور کلی تغییراتی را در یک پیاده سازی پیشنهاد می کنند، اما نه در پایه کد اتریوم. اینها اغلب نیاز به اجماع جامعه دارند، برخلاف EIPهای اطلاعاتی، کاربران آزاد نیستند که آنها را نادیده بگیرند.
نمونه بارز این نوع EIP را می توان در تغییر رویه ها و دستورالعمل ها در فرآیند تصمیم گیری و تغییرات در ابزارها یا محیط مورد استفاده در توسعه اتریوم مشاهده کرد.
هر هدف EIP نیز یک EIP فرآیند در نظر گرفته می شود.
خبرنامه ها
یک EIP اطلاعاتی یک مشکل طراحی اتریوم را توصیف می کند، یا راهنمایی یا اطلاعات کلی را به جامعه اتریوم ارائه می دهد، اما ویژگی جدیدی را پیشنهاد نمی کند.
EIP های اطلاعاتی لزوماً اجماع یا توصیه های جامعه اتریوم را نشان نمی دهند، بنابراین کاربران و مجریان می توانند EIP های اطلاعاتی را نادیده بگیرند یا توصیه های آنها را دنبال کنند.
نحوه عملکرد پیشنهادات بهبود اتریوم یا EIP
عملکرد EIP ها به وضوح در EIP-001 تعریف شده است. این فرآیند با فرآیند تولید ایده یا پیشنهاد توسط نویسنده EIP آغاز می شود.
در این مرحله، مسئولیت توسعه بر عهده نویسنده است و این اوست که باید دلایل لازم را برای اثبات نیاز پیشنهاد خود و همچنین دفاع از آن ارائه کند.
به همین دلیل، نویسنده EIP باید یک ایده واضح و واضح ایجاد کند و آن را همراه با توجیه و عناصری که ارائه آن را پشتیبانی می کند، در بدنه EIP ارائه کند.
بنابراین در این مرحله مراحل زیر را داریم:
نحوه عملکرد پیشنهادات بهبود اتریوم یا EIP
عملکرد EIP ها به وضوح در EIP-001 تعریف شده است. این فرآیند با فرآیند تولید ایده یا پیشنهاد توسط نویسنده EIP آغاز می شود.
در این مرحله، مسئولیت توسعه بر عهده نویسنده است و این اوست که باید دلایل لازم را برای اثبات نیاز پیشنهاد خود و همچنین دفاع از آن ارائه کند.
به همین دلیل، نویسنده EIP باید یک ایده واضح و واضح ایجاد کند و آن را همراه با توجیه و عناصری که ارائه آن را پشتیبانی می کند، در بدنه EIP ارائه کند.
بنابراین در این مرحله مراحل زیر را داریم:
مرحله اول: ارائه ایده
این ابتدایی ترین و صیقل نشده ترین مرحله یک EIP است.
اساساً این ارتقا را به عنوان یک پیشنهاد در انجمن های اتریوم ارائه می دهد.
هدف از این امر دریافت بازخورد از جامعه، ادامه یا عدم ادامه توسعه پیشنهاد به روشی دقیق تر است.
مرحله دوم: ایجاد پیش نویس
در این مرحله این ایده از قبل با پیروی از پارامترهای سازمانی مورد انتظار از یک EIP تجسم و اجرا شده است.
این یک فعالیت فعال و در حال انجام است که در آن می توانید درخواست های بعدی را با تغییرات بیشتر در پیش نویس خود ارسال کنید تا جایی که فکر می کنید EIP بالغ و آماده انتقال به حالت بعدی است.
مرحله سوم: آخرین تماس
در این مرحله پیش نویس اصلاح شده در وب سایت EIPS Ethereum نمایش داده می شود.
ایده این مرحله ارائه EIP به بیشترین تعداد افراد جامعه، اصلاحات کامل و ایجاد یک اجرای کاملاً کاربردی و بازنگری شده از EIP است.
مرحله چهارم: پذیرش
این وضعیت نشان می دهد که تغییرات مواد بعید است و توسعه دهندگان مشتری اتریوم باید این EIP را برای گنجاندن در نظر بگیرند.
فرآیند شما برای تصمیم گیری در مورد تغییر آن در مشتریان خود به عنوان بخشی از هارد فورک، بخشی از فرآیند EIP نیست.
این وضعیت فقط برای EIPها برای فرآیندهای بلاک چین اصلی قابل اجرا است.
مرحله پنجم: ارائه نهایی
این نقطه حالتی را نشان می دهد که در آن EIP باید فقط برای تصحیح چاپ اشتباه به روز شود. علاوه بر این، حالت های دیگر را می توان علامت گذاری کرد مانند:
دارایی ها: در برخی از EIP های اطلاعاتی و پردازشی، اگر هرگز نیاز به تکمیل نداشته باشند، می توانند وضعیت “فعال” را نیز داشته باشند.
لغو شد: نویسندگان اصلی دیگر به دنبال اجرای این EIP نیستند یا ممکن است دیگر یک گزینه ترجیحی (از لحاظ فنی) نباشد.
Rejected: یک EIP که اساساً شکسته است یا یک Core EIP که توسط Core Devs رد شده است و اجرا نخواهد شد.
جایگزین شده: یک EIP که قبلاً نهایی بود، اما دیگر به عنوان پیشرو در نظر گرفته نمی شود.
EIP دیگری در حالت Final خواهد بود و به EIP جایگزین شده اشاره خواهد کرد. فرمت پیشنهادهای بهبود اتریوم یا EIP
البته پیشنهادهای بهبود اتریوم یا EIP که اسناد فنی هستند، یک قالب ارائه استاندارد دارند که به وضوح تمام اطلاعات لازم برای درک بهبود پیشنهاد شده توسط آن را نشان می دهد. بنابراین ما دریافتیم که فرمت EIP شامل خطوط زیر است:
مقدمه این مقدمه ای برای EIP است. آنها بر اساس راهنمای سبک ایجاد شده توسط استاندارد RFC 822 فرمت می شوند.
این مقدمه شامل تمام داده های اساسی EIP، مانند شماره آن، نویسنده آن، نام و توضیح مختصری است. سفارش شما.
در این مرحله مختصری خواهیم یافت.
شرح (بیش از ۲۰۰ کلمه) مشکل فنی که در EIP به آن پرداخته شده است.
انگیزه. این نقطه اختیاری است و فقط در صورتی باید اجباری باشد که بخواهید پروتکل اتریوم را تغییر دهید.
در این مرحله، نویسنده EIP باید به وضوح توضیح دهد که چرا مشخصات پروتکل موجود برای رسیدگی به مشکلی که EIP حل می کند ناکافی است.
ارسال های EIP بدون انگیزه قانع کننده در این مرحله ممکن است به طور کامل رد شود. مشخصات.
در این مرحله نویسنده EIP باید نحو و بهبودی را که پیشنهاد می کند ایجاد و توضیح دهد.
باید واضح و مختصر، قابل اثبات و قابل تکرار باشد. اگر مشخصات این اصول را رعایت نکند، به سادگی رد خواهد شد.
توجیه. توجیه، مشخصات را با توصیف انگیزه طراحی و چرایی تصمیمات طراحی خاص توسعه می دهد.
باید طرح های جایگزینی را که در نظر گرفته شده و کارهای مرتبط را تشریح کند.
توجیه همچنین می تواند شواهدی مبنی بر اجماع در جامعه ارائه دهد و باید به اعتراضات یا نگرانی های مهم مطرح شده در طول بحث رسیدگی کند.
سازگاری به عقب تمام EIP هایی که ناسازگاری های عقب مانده را معرفی می کنند باید شامل بخشی باشند که این ناسازگاری ها و شدت آنها را توضیح دهد.
EIP باید توضیح دهد که نویسنده چگونه پیشنهاد می کند که این تناقضات را برطرف کند.
موارد ارسالی EIP بدون معاهده سازگاری عقب مانده کافی ممکن است به طور کامل رد شوند.
موارد آزمون. موارد آزمایشی برای پیاده سازی برای EIP هایی که بر تغییرات اجماع تأثیر می گذارند مورد نیاز است.
سایر EIP ها ممکن است در صورت وجود پیوندهایی را به موارد آزمایشی اضافه کند.
پیاده سازی ها استقرارها باید قبل از اینکه هر EIP وضعیت “نهایی” را دریافت کند، تکمیل شود، اما نیازی به تکمیل قبل از ادغام EIP به عنوان پیش نویس نیست.
در حالی که رویکرد دستیابی به اجماع در مورد مشخصات و توجیه قبل از نوشتن کد دارای شایستگی است، اصل “توافق عمومی و اجرای کد” هنوز در هنگام تلاش برای حل بسیاری از بحث ها در مورد جزئیات API مفید است.
حظات امنیتی همه EIP ها باید شامل بخشی باشند که مفاهیم امنیتی / ملاحظات مربوط به تغییر پیشنهادی را مورد بحث قرار دهد.
شامل اطلاعاتی باشد که ممکن است به بحث های امنیتی، خطرات سطحی مرتبط باشد و در طول چرخه عمر پیشنهاد مورد استفاده قرار گیرد.
به عنوان مثال. آنها شامل تصمیمات طراحی مرتبط با امنیت، نگرانیها، بحثهای مهم، راهنماییها و مشکلات پیادهسازی خاص، خلاصهای از تهدیدها و خطرات و نحوه رسیدگی به آنها میشوند.
موارد ارسالی EIP که در بخش “ملاحظات امنیتی” وجود ندارد رد خواهند شد.
یک EIP نمی تواند به حالت “نهایی” برود بدون اینکه یک بحث ملاحظات امنیتی توسط بازبینان کافی تلقی شود.
معافیت حق چاپ همه EIP ها باید در حوزه عمومی باشند.
