Jump’s Firedancer پیشنهاد حذف محدودیتهای ثابت بلاک Solana و مقیاسپذیری با قدرت اعتبارسنج را ارائه میدهد

پیشنهاد Firedancer برای حذف محدودیتهای ثابت بلاک در سولانا
تیم Firedancer متعلق به Jump Trading پیشنهاد حذف محدودیتهای ثابت واحد محاسباتی (compute unit) بلاک در سولانا را ارائه داده که به اعتبارسنجها اجازه میدهد ظرفیت تراکنش را به صورت پویا بر اساس عملکرد سختافزاری خود مقیاسدهی کنند، نه بر اساس محدودیتهای قراردادی خودسرانه. پیشنهاد SIMD-0370 مشوقهای بازار-محور ایجاد میکند که در آن تولیدکنندگان بلاک به طور مداوم تجهیزات خود را ارتقا میدهند تا تراکنشهای بیشتری را بستهبندی کرده و درآمد بالاتری کسب کنند.
پسزمینه: ارتقاء اجماع Alpenglow
این پیشنهاد در پی ارتقاء اجماع آلپنگلو (Alpenglow) سولانا مطرح شده که با حمایت قاطع ۹۹.۶۰ درصدی اعتبارسنجها و ۱۴۹.۳ میلیون SOL رای موافق به تصویب رسید. آلپنگلو مکانیسمهای رای-جهشی (skip-vote) معرفی میکند که با دور زدن خودکار بلاکهایی که اجرای آنها بیش از حد طول میکشد، محدودیتهای ثابت بلاک را زائد میسازد.
محدودیتهای سیستم فعلی
در سیستم فعلی، ظرفیت شبکه به صورت مصنوعی توسط محدودیتهای واحد محاسباتی مهار شده، نه توسط قابلیتهای واقعی اعتبارسنجها. Firedancer استدلال میکند که این امر مشوقهای معکوس ایجاد میکند، جایی که سختافزار برتر هیچ مزیت رقابتی ارائه نمیدهد و در نتیجه نوآوری و رشد شبکه را خفه میکند.
نگرانیهای مطرح شده
با این حال، علیرغم نوآورانه بودن، این پیشنهاد بحثهایی را در جامعه برانگیخته است. منتقدان در مورد خطر تمرکزگرایی بالقوه هشدار دادهاند. آنها استدلال کردهاند که اعتبارسنجهای دارای سختافزار گرانقیمت میتوانند تسلط یابند، در حالی که اپراتورهای کوچکتر برای همگام شدن تقلا میکنند. دیگران نیز در مورد سازگاری با طراحیهای آینده پیشنهاددهنده همزمان چندگانه (multiple concurrent proposer) که ممکن است به محدودیتهای اجرای همگامسازی شده نیاز داشته باشند، سوال کردهاند.
مسابقه تسلیحاتی سختافزاری و دگرگونی اقتصاد شبکه
این پیشنهاد یک چرخطوفان رقابتی ایجاد خواهد کرد که در آن تولیدکنندگان بلاک باید به طور مداوم عملکرد خود را بهبود بخشند تا کارمزدهای تراکنش را به حداکثر رسانده و سهم بازار خود را حفظ کنند. اعتبارسنجهایی که نرمافزار کلاینت کندتری اجرا میکنند با کاهش سودآوری مواجه شده، که مشوق پذیرش سریع بهبودهای عملکرد در سراسر اکوسیستم خواهد بود.
رقابت و نوآوری
توسعهدهندگان Firedancer استدلال میکنند که کلاینتهای اعتبارسنج برتر سهم بازار بیشتری به دست خواهند آورد، زیرا اپراتورها به دنبال پاداشهای بالاتر هستند. این رقابت چرخههای نوآوری سریعتری را در مقایسه با افزایش محدودیتهای دستی که نیاز به اجماع جامعه و دورههای پیادهسازی طولانی دارند، به راه خواهد انداخت.
دینامیک رقابت و حلقههای بازخورد
این سیستم بر پویایی رقابت اشتاکلبرگ (Stackelberg) متکی است، جایی که تولیدکنندگان بلاک ظرفیت شبکه را از طریق بلاکهای کمی بزرگتر سیگنالدهی میکنند و ارتقاءها را بدون ارتباط صریح هماهنگ میکنند. اعتبارسنجهایی که قادر به پردازش این بلاکهای بزرگتر نباشند، از آنها عبور میکنند و حلقههای بازخورد طبیعی ایجاد میشود که از تشکیل اندازههای بلاک بیش از حد جلوگیری میکند.
نگرانیهای تمرکزگرایی
منتقدان نگرانیهایی در مورد فشارهای تمرکزگرایی مطرح کردهاند، زیرا مجاورت جغرافیایی با تولیدکنندگان بلاک مزایای اجرایی فراهم میکند. علاوه بر این، اعتبارسنجهایی که برای رقابتی ماندن نیاز به ارتقاء سختافزاری پرهزینه دارند، ممکن است اپراتورهای کوچکتر را به طور کامل از شبکه حذف کنند.
اعضای جامعه پرسیدهاند که آیا اعتبارسنجهای جدید میتوانند در صورت افزایش سریع پیچیدگی بلاک، از اسنپشاتها (snapshots) همگامسازی کنند یا خیر. این پیشنهاد این Risks را تصدیق میکند اما استدلال میکند که عملکرد ریپلی (replay) معمولاً از سرعت تولید بلاک پیشی میگیرد و موانع معقولی برای مشارکت در شبکه حفظ میکند.
موانع فنی و چالشهای جدول زمانی پیادهسازی
به عنوان یک پیشنهاد جدید، بحثهای توسعهدهندگان نگرانیهای قابل توجهی در مورد سازگاری با ارتقاءهای آینده پروتکل، به ویژه معماریهای پیشنهاددهنده همزمان چندگانه (multiple concurrent proposer) که ممکن است به محدودیتهای بلاک برای اجرای ناهمزمان نیاز داشته باشند، آشکار ساخته است. تیم Firedancer استدلال میکند که این ویژگیها هنوز نامشخص هستند و نباید بهبودهای فعلی را محدود کنند.
حالتهای شکست بالقوه و راهکارهای کاهش
بازخورد جامعه همچنین حالتهای شکست بالقوه در خلال مقیاسدهی سریع ظرفیت را برجسته کرده است، از جمله سناریوهایی که در آن سرعتهای اجرایی پیشرونده میتوانند شبکهها را به زیر آستانههای رای بحرانی سوق دهند. برخی از توسعهدهندگان کوتاه کردن اپاک (epoch) را به عنوان راهکار کاهش پیشنهاد کردهاند، اگرچه این رویکرد پیچیدگی اضافی به همراه دارد.
هماهنگی و پیادهسازی
این پیشنهاد نیاز به هماهنگی دقیق مکانیسمهای تایماوت در پیادهسازیهای مختلف اعتبارسنج دارد، زیرا روشهای لغو اجرا به طور قابل توجهی بین کلاینتها متفاوت است. طراحیهای فعلی باید انتشار مناسب بلاک را از طریق پشتههای شبکهای (networking stacks) بدون ایجاد گلوگاه یا شکست انتشار تضمین کنند.
نیاز به چارچوبهای آزمایشی جامع
چندین اعتبارسنج حذف محدودیتهای مصنوعی را حمایت کردهاند، در حالی که خواستار چارچوبهای آزمایشی جامع قبل از پیادهسازی هستند.