سولانا تاریخ ۹ سپتامبر را برای تراکنش نسخه ۱ (Transaction v1) هدف قرار داده است، فرمتی جدید که حداکثر اندازه تراکنش سریال‌شده را از ۱,۲۳۲ بایت به ۴,۰۹۶ بایت افزایش می‌دهد.

این افزایش، حدود ۳.۳ برابر فضای تراکنش بیشتری را در اختیار توسعه‌دهندگان قرار می‌دهد. نقشه راه رسمی سولانا بیان می‌کند که ظرفیت اضافی می‌تواند از اثبات‌های دانش صفر (zero-knowledge proofs)، عملیات‌های چندامضایی (multisignature) بزرگ، دسته‌ها (batches) و برخی از طرح‌های امضای درون‌زنجیره‌ای (onchain signature schemes) پشتیبانی کند.

عملیات‌های بزرگ قبلاً باید به چندین تراکنش تقسیم می‌شدند، زمانی که دستورالعمل‌ها، امضاها و اطلاعات حساب آنها از سقف ۱,۲۳۲ بایت فراتر می‌رفت. این فرآیند پیچیدگی ایجاد می‌کرد زیرا یک تراکنش می‌توانست موفق شود در حالی که مرحله دیگری شکست می‌خورد.

تراکنش نسخه ۱ می‌تواند به توسعه‌دهندگان اجازه دهد که تعداد بیشتری از این دستورالعمل‌ها را در یک عملیات اتمیک (atomic operation) ترکیب کنند. یا هر دستورالعمل موفق می‌شود یا کل تراکنش شکست می‌خورد. این مدل می‌تواند به مسیرهای معاملاتی، نقل و انتقالات محرمانه، عملیات‌های بین‌زنجیره‌ای (cross-chain) و برنامه‌هایی که اثبات‌های رمزنگاری پیچیده را پردازش می‌کنند، سود برساند.

این ارتقاء محدودیت سولانا برای ۶۴ حساب ارجاع‌داده شده در هر تراکنش را افزایش نمی‌دهد. برنامه‌ها می‌توانند داده‌ها و دستورالعمل‌های بیشتری را شامل شوند، اما نمی‌توانند به طور خودکار با حساب‌های بیشتری تعامل داشته باشند.

تراکنش‌های موجود سولانا معتبر باقی خواهند ماند

تراکنش نسخه ۱ اختیاری است. کیف پول‌ها و برنامه‌ها می‌توانند تراکنش‌های قدیمی (legacy) و نسخه ۰ (v0) را تحت محدودیت ۱,۲۳۲ بایتی موجود ارسال کنند. کاربران نیازی به مهاجرت توکن‌ها، مبادله SOL یا تکمیل یک مطالبه (claim) قبل از فعال‌سازی ندارند.

توسعه‌دهندگان باید عمداً فرمت جدید را برای دسترسی به ظرفیت بزرگتر آن اتخاذ کنند. مستندات سولانا سه فرمت پشتیبانی‌شده را مشخص می‌کند: قدیمی (legacy)، نسخه ۰ (v0) و نسخه ۱ (v1). هر فرمت، آدرس‌های حساب و محدودیت‌های منابع را به طور متفاوتی سازماندهی می‌کند.

فرمت نسخه ۰ از جدول‌های جستجوی آدرس (Address Lookup Tables) یا ALTs برای نمایش آدرس‌های حساب از طریق شاخص‌های فشرده یک بایتی استفاده می‌کند. نسخه ۱ ALTs را حذف می‌کند و آدرس‌های کامل ۳۲ بایتی حساب را مستقیماً درون تراکنش قرار می‌دهد.

این یک بده‌بستان (trade-off) ایجاد می‌کند. نسخه ۱ یک پاکت کلی بزرگتر را فراهم می‌کند، اما برنامه‌هایی که به شدت به جدول‌های جستجو متکی هستند، ممکن است بایت‌های بیشتری را برای نمایش همان حساب‌ها مصرف کنند. تحلیل فنی سولانا نشان داد که ۹۰٪ از تراکنش‌های نمونه‌برداری‌شده هنگام تبدیل از نسخه ۰ به نسخه ۱، کمتر از ۱,۴۰۰ بایت اضافه خواهند کرد.

ارائه‌دهندگان زیرساخت باید نرم‌افزار خود را به‌روزرسانی کنند

خطر اصلی سازگاری متوجه خدماتی است که بلاک‌ها و تراکنش‌ها را می‌خوانند. ارائه‌دهندگان فراخوانی رویه‌های از راه دور (Remote procedure call providers) باید حداکثر نسخه تراکنش پشتیبانی‌شده خود را روی یک تنظیم کنند. در غیر این صورت، درخواست‌ها ممکن است در مواجهه با تراکنش نسخه ۱ با شکست مواجه شوند.

فهرست‌سازها (indexers)، کاوشگرها (explorers) و خدمات تحلیلی نیز باید نحوه بازیابی محدودیت‌های منابع را تغییر دهند. تراکنش‌های قدیمی (legacy) و نسخه ۰ (v0) محدودیت‌های محاسباتی (compute limits) و تنظیمات کارمزد اولویت (priority-fee) را درون دستورالعمل‌های ComputeBudget قرار می‌دهند. نسخه ۱ آنها را در یک پیکربندی تراکنش اختصاصی ذخیره می‌کند.

بنابراین، خدمات منسوخ شده ممکن است اطلاعات نادرستی را نمایش دهند. برای مثال، یک کاوشگر ممکن است کارمزد اولویت (priority fee) صفر را نشان دهد، حتی اگر کاربر آن را پرداخت کرده باشد. حامیان مالی کارمزد و برنامه‌هایی که محدودیت‌های تراکنش را بررسی می‌کنند، باید پیکربندی جدید را بخوانند، نه اینکه دستورالعمل‌های قدیمی را اسکن کنند.

برنامه‌هایی که تراکنش‌های نسخه ۱ را ارسال می‌کنند، باید به طور صریح محدودیت‌های واحد محاسباتی (compute-unit) و داده‌های بارگذاری شده (loaded-data) را تنظیم کنند، زیرا هر دو به طور پیش‌فرض صفر هستند. توسعه‌دهندگان باید ساخت، امضا و رمزگشایی تراکنش را قبل از انتقال ترافیک عملیاتی به این فرمت آزمایش کنند.

۹ سپتامبر همچنان تاریخ فعال‌سازی هدف است

جاکوب کریچ، معاون رئیس فناوری بنیاد سولانا، ۹ سپتامبر را به عنوان تاریخ برنامه‌ریزی‌شده برای شبکه اصلی (mainnet) مشخص کرد. همانطور که crypto.news قبلاً گزارش داده بود، این ارتقاء در عرضه Agave 4.2 آنزا گنجانده شده است.

با این حال، نقشه راه رسمی هنوز این ویژگی شبکه اصلی (mainnet) را به عنوان "فعال نشده" (not activated) برچسب‌گذاری کرده است. همچنین بیان می‌کند که برنامه انتشار آنزا "آزمایشی و قابل تغییر" است. طبق آخرین صفحه وضعیت بنیاد، شبکه آزمایشی (testnet) و شبکه توسعه‌دهنده (devnet) قبلاً این ویژگی را فعال کرده‌اند.

افزایش اندازه از SIMD-0296 ناشی می‌شود، در حالی که SIMD-0385 فرمت نسخه ۱ را تعریف می‌کند. جاکوب کریچ و اندرو فیتزجرالد هر دو پیشنهاد را به طور مشترک تألیف کرده‌اند.

سقف ۴,۰۹۶ بایتی تا حدی به این دلیل انتخاب شد که چهار کیلوبایت با اندازه رایج صفحه حافظه که توسط سخت‌افزار اعتبارسنج (validator) استفاده می‌شود، مطابقت دارد. تراکنش‌های بزرگتر همچنین پهنای باند اضافی مصرف خواهند کرد، اگرچه این ارتقاء هیچ کارمزد جداگانه‌ای به ازای هر بایت معرفی نمی‌کند.

تراکنش نسخه ۱ از کاهش اجاره سولانا (rent reductions)، اهداف اسلات کوتاه‌تر (shorter slot targets) و بازطراحی اجماع Alpenglow جدا باقی می‌ماند. در پوشش خبری مرتبط، crypto.news گزارش داد که Alpenglow تقریباً نهایی شدن ۱۵۰ میلی‌ثانیه‌ای را هدف قرار داده است، در حالی که اکتبر یک هدف توسعه‌ای باقی می‌ماند و نه یک تاریخ فعال‌سازی تضمین شده.