۱۰۰ میلیون CU و هاتاسپاتهای ۱۲ میلیونی: چرا ارتقای ظرفیت سولانا، ارتقای پردازش موازی است
سولانا در ۲۹ ژوئیهٔ ۲۰۲۶ سقف محاسبات هر بلاک را از ۶۰ میلیون به ۱۰۰ میلیون CU افزایش داد. از آنجا که سقف ۱۲ میلیون CU برای نوشتن روی هر حساب تغییر نکرده است، دستاورد عملی این ارتقا فضای بیشتر برای بارهای کاری مستقل است، نه بودجهای بزرگتر برای یک ماشین حالت پرتراکم.
نکات کلیدی
- • سولانا در ۲۹ ژوئیهٔ ۲۰۲۶ سقف محاسبات هر بلاک را از ۶۰ میلیون به ۱۰۰ میلیون CU افزایش داد
- • از آنجا که سقف ۱۲ میلیون CU برای نوشتن روی هر حساب تغییر نکرده است، دستاورد عملی این ارتقا فضای بیشتر برای بارهای کاری مستقل است، نه بودجهای بزرگتر برای یک ماشین حالت پرتراکم

بلاکی بزرگتر، نه تراکنشی بزرگتر
سولانا در ۲۹ ژوئیهٔ ۲۰۲۶ و در آغاز اپوک ۱۰۰۹، SIMD-0286 را فعال کرد و حداکثر واحدهای محاسباتی مجاز در هر بلاک را از ۶۰ میلیون به ۱۰۰ میلیون افزایش داد؛ یعنی ۶۶٪ افزایش ظرفیت. این یک ارتقای فعالشده در میننت است، نه پیشنهادی که هنوز منتظر انتشار باشد؛ سولانا نیز آن را بدون تغییر ناسازگار و بدون نیاز به تغییر در ایندکسسازی توصیف میکند.
نکتهٔ مهم برای توسعهدهندگان این است که این تغییر در سطح بلاک انجام شده است. این ارتقا مجموع کاری را که یک لیدر میتواند در بلاک بگنجاند افزایش میدهد. نه یک تراکنش را ۶۶٪ بزرگتر میکند و نه همهٔ محدودیتهای منابع پیرامون آن تراکنش را افزایش میدهد.
تغییر مهمی که رخ نداد: حسابهای داغ همچنان در ۱۲ میلیون متوقف میشوند
SIMD-0286 فقط حداکثر محاسبات بلاک را تغییر میدهد. سقف محاسبات برای حساب قابلنوشتن همچنان ۱۲ میلیون CU و سقف تغییر اندازهٔ دادهٔ حسابها در بلاک همچنان ۱۰۰ مگابایت است.
| محدودیت | پیش از ارتقا | پس از ارتقا | معنای عملی |
|---|---|---|---|
| حداکثر محاسبات بلاک | ۶۰ میلیون CU | ۱۰۰ میلیون CU | مجموع کار بیشتری در یک بلاک جا میگیرد. |
| حداکثر محاسبات برای هر حساب قابلنوشتن | ۱۲ میلیون CU | ۱۲ میلیون CU | یک حساب با نوشتن سنگین همچنان همان سقف هر بلاک را دارد. |
| تغییر اندازهٔ دادهٔ حسابها در بلاک | ۱۰۰ مگابایت | ۱۰۰ مگابایت | این ارتقا این مرز رشد حالت را بزرگتر نمیکند. |
به همین دلیل، این ارتقا در درجهٔ نخست دربارهٔ ظرفیت موازی است. در سقف قبلی، یک حساب داغ ۱۲ میلیون-CU میتوانست تا ۲۰٪ یک بلاک پر را تشکیل دهد؛ در سقف ۱۰۰ میلیون CU، همان حساب ۱۲٪ بلاک است. اگر آن حساب به سقف خود برسد، فضای نظری باقیمانده برای فعالیتهای نامرتبط از ۴۸ میلیون به ۸۸ میلیون CU میرسد. این محاسبه تضمین تأخیر نیست، اما هدف طراحی را نشان میدهد: یک حساب پرتراکم باید سهم کمتری از بلاک در دسترس برای حسابهای نامرتبط را اشغال کند.
تیمهای اپلیکیشن چه کاری باید انجام دهند
-
برای افزایش بودجهٔ یک تراکنش برنامهریزی نکنید. مانند گذشته محاسبات تراکنش را اندازهگیری و شبیهسازی کنید. این ارتقا فضای تجمیعی بلاکها را بیشتر میکند؛ دلیلی برای افزایش بیرویهٔ محاسبات درخواستی یک تراکنش موجود نیست.
-
تمرکز نوشتن را پروفایل کنید. برنامهای که در اوج فعالیت، بارها روی یک استخر، خزانه، بازار، مینت یا حساب حالت سراسری مینویسد، همچنان میتواند با سقف تغییرنکردهٔ ۱۲ میلیون CU روبهرو شود. افزایش ظرفیت زمانی بیشتر دیده میشود که کار میان حسابهای قابلنوشتن مستقل پیش برود.
-
فقط در صورت سازگاری با معنای برنامه، شاردینگ را بررسی کنید. تفکیک بازارها، کاربران یا باکتهای مستقل میتواند یک گلوگاه واقعیِ نوشتن را کاهش دهد. اما صرفاً برای رسیدن به توان عملیاتی، حالت را تکهتکه نکنید؛ اگر برنامه به ترتیبدهی سراسری اتمیک یا ناورداییهای مشترک نیاز دارد، درستی در اولویت است.
-
خط لولههای خواندن و داده را زیر بار آزمایش کنید. سولانا میگوید ارائهدهندگان RPC، ایندکسرها و صرافیها باید سامانههای خود را در برابر بلاکهای پایدار ۱۰۰ میلیون-CU بررسی کنند، حتی اگر قالب دادهٔ بلاک تغییر نکرده باشد. تیمهایی که بلاکها را بازپخش میکنند، تراکنشها را دریافت میکنند یا کارهای دستهای مبتنی بر اسلات دارند، باید توان عملیاتی و رفتار همگامسازی مجدد خود را آزمایش کنند.
-
ظرفیت را فضای تنفس بدانید، نه وعدهٔ سطح خدمت. بنیاد سولانا گزارش میکند که از فعالسازی سقف ۶۰ میلیون در ۲۲ ژوئیهٔ ۲۰۲۵ تا این افزایش، ۱۱٫۲٪ بلاکها دستکم ۵۶ میلیون CU مصرف کردهاند. بنابراین سقف جدید در جهشهای واقعی تقاضا اهمیت دارد، اما یک تراکنش منفرد همچنان میتواند بهدلیل مصرف محاسباتی خودش و رقابت بر سر حسابهایی که باید روی آنها بنویسد محدود شود.
تغییری که باید در معماری ذهنی ایجاد شود
برای توسعهدهندگان، مدل ذهنی مفید این نیست که «برنامهٔ من ۶۶٪ قدرت بیشتر گرفت». مدل درست این است که «شبکه میتواند کارهای مستقل بیشتری را در کنار برنامهٔ من جا دهد». یک حساب مشترک و پرتراکم همچنان گلوگاه میماند؛ اما بار کاریای که با ایمنی میان حسابهای متمایز توزیع شده باشد، در دورههای شلوغی فضای بیشتری برای ثبت شدن دارد.
این موضوع، توپولوژی حالت را به یک تصمیم عملکردی درجهیک تبدیل میکند. حالت مشترک قابلنوشتن را آگاهانه کوچک نگه دارید، حسابهایی را که ترافیک اوج را جذب میکنند شناسایی کنید، و جریانهای مستقل را طوری طراحی کنید که مستقل باقی بمانند. ارتقای ۱۰۰ میلیون-CU سولانا به این انضباط پاداش میدهد و همزمان محافظهایی را حفظ میکند که مانع از انحصار کل یک بلاک توسط یک حساب میشوند.
برچسبها
منابع و ارجاعات مستند
پیشنهاد مطالعه بعدی

بازسازی لایه خواندن: نگاهی به جداسازی RPC 2.0 سولانا و عصر Anchor v1.0.0

بکاند حاکمیتی: نگاهی به فتح دوگانه امور مالی سازمانی و اقتصاد عوامل هوش مصنوعی توسط سولانا

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