گلمدام، ارتقای بزرگ اتریوم، قراردادهای هوشمند قدیمی را با چالش مواجه میکند
ارتقای بزرگ بعدی اتریوم، موسوم به گلمدام (Glamsterdam)، با بازنگری در قیمتگذاری گس (Gas)، میتواند گروهی از قراردادهای هوشمند را که با فرض قیمتهای قدیمی نوشته شدهاند و قابل تغییر نیستند، از کار بیندازد. دو توسعهدهنده روز یکشنبه پیشنویسهای رقیبی را برای رفع این مشکل ارائه کردند. یک رویکرد، اجازه میدهد قراردادهای قدیمی با نرخهای قبلی به کار خود ادامه دهند و تنها قراردادهای جدید از سیستم جدید پیروی کنند. رویکرد دیگر، قیمتهای جدید را اعمال میکند اما با استفاده از دو سیستم حسابداری، تغییر قیمت را برای قراردادهای قدیمی نامحسوس نگه میدارد. هر دو طرح هنوز در مرحله پیشنویس هستند و جدول زمانی مشخصی ندارند.
ریشه مشکل: تغییرات اساسی در هزینههای گس
منشأ این مشکل، دو پیشنهاد در گلمدام است که قیمتگذاری را تغییر میدهند. EIP-8037 هزینه پایه ایجاد قرارداد را از ۳۲,۰۰۰ گس به ۱۸۳,۶۰۰ گس افزایش میدهد، که این مبلغ هزینه ذخیره کد و اجرای بعدی را در بر نمیگیرد. EIP-8038 نیز هزینه خواندن و نوشتن دادهها در حافظه زنجیره را افزایش میدهد. گس واحدی است که اتریوم برای هر عملیات محاسباتی قیمتگذاری میکند و با تغییر قیمت آن، تمام برنامههای وابسته به آن تحت تأثیر قرار میگیرند.
بسیاری از برنامههای دیفای (DeFi) با این فرض نوشته شدهاند که “این هزینهها هرگز تغییر نخواهند کرد”. برخی از این برنامهها هنگام فراخوانی یک قرارداد دیگر، سقف گس ثابتی را در نظر میگیرند و اگر هزینه طرف مقابل افزایش یابد، این فراخوانی مستقیماً با شکست مواجه میشود. مشکل پیچیدهتر این است که قراردادهای هوشمند پس از استقرار قابل تغییر نیستند؛ این یک نقص نیست، بلکه یک ویژگی طراحی است. تنها کاری که توسعهدهندگان میتوانند انجام دهند، استقرار یک نسخه جدید است، اما وجوه قفل شده در قراردادهای قدیمی به طور خودکار منتقل نمیشوند.
راهحلهای پیشنهادی: دو مسیر متفاوت
لئو گلیسیک (Leo Glisic) راه حلی را پیشنهاد کرده است که مجموعه دستورالعملها را به دو بخش تقسیم میکند. پیشنویس EIP-8488 او پیشنهاد میکند که قراردادهای موجود از جدول نرخگذاری قدیمی استفاده کنند، در حالی که قراردادهای جدید باید از opcodeهای V2 استفاده کرده و مستقیماً قیمتهای جدید EIP-8037 و EIP-8038 را اعمال کنند. مزیت این رویکرد این است که رفتار قراردادهای قدیمی کاملاً بدون تغییر باقی میماند، اما هزینه آن این است که مجموعه دستورالعملهای اتریوم به دو نسخه تقسیم میشود و نودها باید هر دو مجموعه قوانین را برای مدت طولانی نگهداری کنند.
جولیو روبوفو (Giulio Rebuffo) رویکرد متفاوتی را در پیش گرفته است: به جای تقسیم مجموعه دستورالعملها، او سیستم حسابداری را تقسیم میکند. طرح “دوگانه حسابداری” او به هر تراکنش اجازه میدهد تا دو سیستم قیمتگذاری را به طور همزمان اجرا کند. یک سیستم فرآیند اجرا را با قوانین قدیمی محاسبه میکند و سیستم دیگر هزینه واقعی دریافت شده را با قوانین جدید محاسبه میکند. به این ترتیب، قراردادهای قدیمی “احساس” تغییر قیمت را نمیکنند و صورتحساب کاربران طبق سیستم جدید محاسبه میشود. این پیشنویس اذعان دارد که این طرح هنوز هیچ پیادهسازی در کلاینتهای اجرایی ندارد و تست اجماع روی آن انجام نشده است.
فشار زمانی و نگرانیهای امنیتی
فشار زمانی واقعی است. گلمدام قرار بود در ۲۶ اکتبر دومین تمرین خود را انجام دهد، اما به دلیل هشدارهای محققان امنیتی به تعویق افتاد. محقق امنیتی pcaversaccio در پلتفرم X به طور مستقیم اعلام کرد که دو هفته پیش مشکل افزایش قیمت گس را به توسعهدهندگان اصلی گزارش داده و نتیجه این بوده که گلمدام نباید با وضعیت فعلی منتشر شود. توسعهدهنده دیگری با نام مستعار banteg اضافه کرد که لیست قراردادهای تحت تأثیر به ۲۰۰,۰۰۰ رسیده است و حتی روششناسی این لیست نیز مشکلاتی دارد، بنابراین تعداد پروتکلهای واقعاً تحت تأثیر احتمالاً بیشتر است. توسعهدهندگان در تاریخ ۲۹ اکتبر، زمان تست بسته بعدی را بین ۱۶ تا ۲۰ نوامبر تخمین زدند، تاریخی که قبل از ارائه این دو پیشنویس تعیین شده بود.
پیامدهای فنی و اقتصادی
برای نودها، طرح گلیسیک نسبتاً سادهتر است؛ قراردادهای قدیمی کاملاً دستنخورده باقی میمانند و بار گذشته را در “نسخهها” محصور میکنند. اما هزینه آن این است که EVM از این پس دو مجموعه دستورالعمل را حمل میکند و شرایط مرزی هنگام فراخوانی قراردادهای جدید و قدیمی باید به طور جداگانه تعریف شوند، در غیر این صورت یک قطعه کد مشابه در نسخههای مختلف نتایج متفاوتی را محاسبه خواهد کرد. در مقایسه، طرح روبوفو کمترین دردسر را برای توسعهدهندگان برنامه دارد؛ صورتحسابهای مشاهده شده توسط کاربران همگی با قیمت جدید محاسبه میشوند، در حالی که قراردادهای قدیمی در یک دفتر حساب دیگر طبق روال قبل اجرا میشوند. مشکل این است که هر تراکنش باید دو بار محاسبه شود و خود پیشنویس اذعان دارد که تست اجماع وجود ندارد. در بدترین حالت، کلاینتهای مختلف ممکن است در شرایط مرزی هزینههای متفاوتی را محاسبه کنند و ریسک اجماع را به اختلافی که صرفاً یک مسئله قیمتگذاری بود، وارد کنند.
در طول ده سال گذشته، ارتقاهای اتریوم عمدتاً از تغییر قیمت گس قراردادهای موجود اجتناب کردهاند، زیرا این امر به عنوان یک قرارداد ضمنی در کل اکوسیستم تلقی میشد. گلمدام اولین بار است که مستقیماً با این موضوع روبرو میشود و این اتفاق تصادفی نیست: بنیاد اتریوم قبلاً هشدار داده بود که برخی کیف پولها و ابزارها به دلیل سیستم جدید گس از کار خواهند افتاد، که نشان میدهد این یک بدهی فنی قابل پیشبینی است. اکنون مسئله این نیست که آیا باید این بدهی را پرداخت کرد، بلکه این است که به چه روشی باید آن را پرداخت.
اگر این مشکل اصلاح نشود، ریسک آن فراتر از “شکست چند تراکنش” خواهد بود. منطق تصفیه (liquidation logic)، تغذیه قیمت اوراکلها و زنجیرههای فراخوانی بین پروتکلها، اگر حتی یک حلقه در این زنجیره به دلیل سقف گس ثابت قطع شود، کل گروهی از موقعیتها در همان زمان دچار مشکل خواهند شد. در پروتکلهای وامدهی، این به معنای عدم امکان تصفیه وامگیرندگانی است که باید تصفیه شوند، یا تصفیه اشتباه آنها است.
اولین نقطه مشاهده، این است که آیا تست بسته بین ۱۶ تا ۲۰ نوامبر طبق برنامه پیش خواهد رفت یا خیر. گلمدام قبلاً یک بار به تعویق افتاده است و اگر دوباره به تعویق بیفتد، برنامه راهاندازی تا پایان سال از دست خواهد رفت. نقطه مشاهده دوم، سرنوشت این دو پیشنویس است: اگر گلمدام پذیرفته شود، به این معنی است که اتریوم علاوه بر بازنگری در قیمتگذاری گس، یک لایه سازگاری اضافی را نیز بر عهده خواهد گرفت. اگر این طرحها به ارتقای بعدی موکول شوند، ممکن است بازنگری در لایه اجماع مانند ePBS و قیمتگذاری گس از هم جدا شوند و توسعهدهندگان مجبور شوند بین “اعمال تغییرات اجماع اول، و به تعویق انداختن مسئله قیمت” دوباره صف بکشند.

Leave a Reply