ویتالیک بوترین شایعات مربوط به تهدید امنیتی موجود در فورک آتی اتریوم را رد کرد
ویتالیک بوترین و توسعه دهندگان اتریوم، در یک گفتگوی اینترنتی که با موضوع بررسی طرح پیشنهادی توسعه اتریوم برگزار شد، در خصوص ادعای پیامد منفی قابلیت جدید فورک آتی اتریوم شفاف سازی کردند.
روز جمعه ۱۵ فوریه (۲۶ بهمن)، ویتالیک بوترین یکی از بنیانگذاران اتریوم و سایر توسعه دهندگان اصلی آن، در جریان یک تماس اینترنتی در یوتیوب، شایعات مربوط به تهدیدهای امنیتی مرتبط با قابلیت جدید ایجاد قرارداد هوشمند در هارد فورک قسطنطنیه را رد کردند.
قابلیت مورد نظر «Create2» نام دارد – که در طرح پیشنهادی بهبود اتریوم (EIP) با کد EIP-1014 تعیین شده بود- و برای ایجاد امکان برقراری تعامل با قراردادهایی در نظر گرفته شده است که هنوز در بلاک چین وجود ندارند – به ویژه «آدرس هایی که هنوز درون زنجیره راه نیفتاده اند، اما ممکن است در نهایت شامل کد باشند.»
با توجه به این احتمال که قراردادهای هوشمند می توانند به گونه ای کدنویسی شوند که بعد از پیاده سازی آدرس خود را تغییر دهند، تعدادی از توسعه دهندگان اتریوم نگرانند که قابلیت «Create2» شرایط وقوع یک حمله جدی به شبکه را فراهم آورد. در جریان گفتگوی مذکور، این پرسش مطرح شد که «آیا قابلیت نامبرده به این معنی نیست که اکنون هرگونه قراردادی بعد از قسطنطنیه، با قابلیت تخریب خودکار (در کد آن)، مشکوک تر از قبل است؟»
در پاسخ به این پرسش و سایر دیدگاه ها جف کولمن (Jeff Coleman)، یکی از توسعه‌دهندگان اتریوم تأکید داشت که «یک ویژگی غیر قابل درک در مورد «Create2» این است که از لحاظ تئوری پیاده سازی مجدد می تواند بایت کد «byte code» قرارداد را تغییر بدهد، چرا که آدرس برای اینیت کد «init code» یک الزام است. باید توجه داشت که اینیت کدها تنها بخشی از فرآیند حسابرسی هستند، […] و اینکه کدهای غیر قطعی (non-deterministic) یک مشکل به شمار می روند.
وی تصریح کرد کسانی که به دنبال بررسی کد دیگران هستند باید مراقب احتمال وقوع «پدیده های عجیب باشند […] به ویژه اگر قابلیت create2 با create1 ترکیب شود، زیرا نانس (nonce) هر چه که باشد، تعهد به هویت آدرس به نسبت در create1 ضعیف تر است. او در ادامه گفت:
نتیجه ای که در آینده انتظارش را داریم […] این است که تمام آدرس ها از طریق اینیت کد، قرارداد داشته باشند. ما به روش آدرس دهی محتوا-محور برای قراردادها نیاز داریم، نه آدرس دهی مبتنی بر درخواست که در (Create1) وجود دارد. بنابرین اگر به جایی برسیم که Create2 استاندارد است و کاملا از قابلیت تخریب خودکار در قراردادها آسوده شویم […] می توانیم ایده یک نانس قرارداد را به طور کامل فراموش کنیم.
ویتالیک بوترین ویتالیک بوترین نیز همانند کولمن با اشاره به یک نقشه راه بلند مدت در زمینه قابلیت Create2 اظهار نظر کرد:
یک نکته را باید در مورد تغییرات Rent و Deletion در نظر داشته باشیم که بیشتر به آینده مربوط می‌شود، این دو روش قراردادها را در وضعیتی فارغ از عملیات تخریب خودکار قرار می دهند […] این امر در هفته های آتی محقق نخواهد شد، اما با توجه به نزدیک بودن زمان پیاده سازی شاردینگ ETH ۲.۰ در مشخصات ماشین مجازی اتریوم، به خاطر داشتن آن ضرری ندارد.
توسعه‌دهندگان علاوه بر بحث در مورد create2، همچنین اعلام کردند که موفق به پیدا کردن یک شرکت مستقل آینده نگر برای تست بنچمارک (سنجش قدرت و مقاومت) یک الگوریتم اثبات انجام کار مقاوم در برابر مدار‌های مجتمع با کاربرد خاص (ASIC) تحت عنوان «ProgPoW» شده اند.
مادامی که اتریوم در مسیر اتخاذ الگوریتم اثبات سهام حرکت می کند، اکثر توسعه دهندگان آن به الگوریتم نامبرده رای مثبت داده اند. اما به تازگی تصمیم گرفته اند که تا زمان اتمام بررسی این الگوریتم توسط یک شخص ثالث، ارائه‌ی آن را به تعویق بیاندازند. نتایج یک نظر‌سنجی آنلاین غیر رسمی نشان می‌دهد که اجرای الگوریتم ProgPoW، مورد حمایت اکثریت جامعه توسعه دهندگان اتریوم است.
درباره زمان اجرای فورک چیزی نگفتند؟