ستُطلق Solana رسميًا تنسيق Transaction v1 على الشبكة الرئيسية في 9 سبتمبر (الأربعاء)، ما يوسّع الحد الأقصى لحجم المعاملة من 1,232 بايتًا إلى 4,096 بايتًا، أي بزيادة تتجاوز ثلاثة أضعاف. وقد عرّف هذا التحديث مقترحا تحسين Solana: SIMD-0296 (المعاملات الأكبر) وSIMD-0385 (تنسيق Transaction v1).
المواصفات التقنية لـ Transaction v1
تُعرَّف Transaction v1 من خلال مقترحَي تحسين Solana؛ إذ يحدد SIMD-0296 الحد الأقصى الجديد لحجم المعاملة، بينما يحدد SIMD-0385 تنسيق Transaction v1. وقد شارك في كتابة المقترحين Jacob Creech وAndrew Fitzgerald. وعملت الميزة الجديدة بصورة مستقرة لفترة من الوقت على شبكتي الاختبار والتطوير، قبل إطلاقها رسميًا على الشبكة الرئيسية في 9 سبتمبر 2026.
صُممت Transaction v1 بحيث تكون متوافقة مع الإصدارات السابقة، ولا يزال تنسيق v0 الحالي صالحًا. ولن تعتمد المحافظ والتطبيقات تنسيق v1 إلا عند الحاجة إلى مساحة أكبر للمعاملة، من دون فرض انتقال إجباري.
الحالات الثلاث الأكثر استفادة مباشرة من Transaction v1
بعد زيادة السعة من 1,232 بايتًا إلى 4,096 بايتًا، ستحصل أنواع المعاملات الثلاثة التالية على أكبر فائدة مباشرة:
براهين التشفير الكبيرة: كانت بيانات التحقق، مثل براهين المعرفة الصفرية (ZK proofs)، تتجاوز في كثير من الأحيان حد 1,232 بايتًا، ما كان يضطر إلى تقسيمها على عدة معاملات. وتتيح Transaction v1 إرسال بيانات التحقق الكاملة لبراهين المعرفة الصفرية ضمن معاملة واحدة.
إجراءات الموافقة متعددة التوقيعات: تتطلب تحويلات الأموال التي تحتاج إلى موافقة عدة موقّعين، مثل خزائن الشركات أو مقترحات المنظمات اللامركزية المستقلة (DAO)، مساحة لكل توقيع. وتتيح v1 إتمام إجراء الموافقة متعدد التوقيعات ضمن معاملة واحدة.
التحويلات السرية: تحتاج بعض آليات المعاملات الخاصة إلى تغليف تشفيري إضافي، ما كان يؤدي إلى فشل المعاملات أو انخفاض كفاءتها بسبب عدم كفاية السعة السابقة. وتوفر سعة 4,096 بايتًا مساحة كافية لهذا النوع من العمليات.
أسباب تحديد الحد الأقصى عند 4,096 بايتًا
يرتبط تحديد الحد الأقصى عند 4,096 بايتًا (4 كيلوبايت) باعتبارات على مستوى الأجهزة؛ فهذا هو حجم صفحة الذاكرة القياسي الذي تستخدمه عقد المدققين. وإذا تجاوزت معاملة واحدة عدة صفحات من الذاكرة، ترتفع تكلفة المعالجة بصورة ملحوظة، ما يضر بالحفاظ على معدل TPS المرتفع في Solana (عدد المعاملات في الثانية). ولذلك تمثل سعة 4 كيلوبايت نقطة توازن بين زيادة السعة والحفاظ على أداء الشبكة.
نشأ حد 1,232 بايتًا القديم من تصميم الشبكة المبكر في Solana، إذ كان يجب أن تتسع كل معاملة داخل حزمة IP يبلغ حجمها نحو 1,280 بايتًا. وفي عام 2022، عدّلت Solana طريقة نقل حركة المعاملات، فلم يعد ذلك السقف الصارم ضروريًا، ويمثل إطلاق Transaction v1 الإزالة الرسمية لهذا القيد التصميمي التاريخي.
التحديثات الضرورية لعقد RPC وخدمات القراءة
يؤثر Transaction v1 في الخدمات التي تقرأ البيانات على السلسلة بدرجة أكبر من تأثيره في كتابة المعاملات. ويجب على جميع الخدمات التي تجلب بيانات الكتل والمعاملات، مثل عقد RPC والأنظمة الخلفية لمزودي بيانات السلسلة والمحافظ، تحديث شيفرتها؛ وإلا فستعيد خطأً فور مواجهة معاملة بتنسيق v1.
ويتمثل تأثير ملموس آخر في موضع حقل رسوم الأولوية؛ إذ تخزّن v1 معلومات رسوم الأولوية في حقل مختلف عن v0. وستعرض البرمجيات القديمة عند قراءة معاملات v1 «رسومًا صفرية»، حتى لو كان المستخدم قد دفع فعليًا رسوم الأولوية. وإذا لم تُحدّث واجهات المحافظ ومستكشفات سلاسل الكتل وتطبيقات المعاملات، فسيشاهد المستخدمون عرضًا غير دقيق للرسوم.
مقارنة السعة مع Ethereum
من منظور تصميم البروتوكول، لا تفرض Ethereum حدًا لحجم المعاملة على مستوى البروتوكول؛ فكل ما يحتاج إليه المطورون هو دفع رسوم Gas أعلى لتنفيذ عمليات كثيفة البيانات ضمن معاملة واحدة. أما Solana، فكانت تفرض سابقًا قيودًا واضحة على عدد التعليمات التي يمكن أن تستوعبها المعاملة الواحدة. وبعد رفع الحد إلى 4,096 بايتًا مع Transaction v1، تقلصت الفجوة بين السلسلتين، لكن 4,096 بايتًا لا تزال سعة صغيرة نسبيًا بالنسبة إلى Ethereum L1؛ إذ تتجاوز معاملة DeFi المركبة والمعقدة على Ethereum، مثل المراجحة بين مجمعات متعددة أو الاقتراض والإقراض عبر أصول متعددة، هذا الرقم في كثير من الأحيان.
وتتمثل الأهمية التقنية العملية لذلك في منظومة Solana في إزالة الحلول الالتفافية التي كان المطورون يعتمدون عليها. فعندما كان يجب تقسيم العمليات على عدة معاملات، كان يتعين التعامل مع تبعيات الحالة بين المعاملات ومشكلات التراجع عند الفشل. وتتيح Transaction v1 تنفيذ المنطق المعقد ضمن عملية ذرية واحدة، بما يجعله أقرب إلى أنماط البرمجة التقليدية.
الأسئلة الشائعة
ما تاريخ إطلاق Solana Transaction v1، وكيف تغير الحد الأقصى للسعة، وما المقترحات التي عرّفته؟
أُطلقت Solana Transaction v1 على الشبكة الرئيسية في 9 سبتمبر 2026 (الأربعاء)، وارتفع الحد الأقصى لحجم المعاملة من 1,232 بايتًا إلى 4,096 بايتًا، أي بزيادة تتجاوز ثلاثة أضعاف. وقد عرّف التحديث مقترحا SIMD-0296 وSIMD-0385، وشارك في كتابتهما Jacob Creech وAndrew Fitzgerald، بعد تشغيله بصورة مستقرة على شبكتي الاختبار والتطوير.
لماذا حُدد الحد الأقصى عند 4,096 بايتًا بدلًا من رقم أكبر؟
يمثل 4,096 بايتًا حجم صفحة الذاكرة القياسي الذي تستخدمه عقد المدققين. وإذا تجاوزت معاملة واحدة عدة صفحات من الذاكرة، ترتفع تكلفة المعالجة بصورة ملحوظة، ما يضر بالحفاظ على معدل TPS المرتفع في Solana. ولذلك تمثل سعة 4 كيلوبايت نقطة توازن بين زيادة السعة والحفاظ على أداء الشبكة.
كيف يجب على عقد RPC وخدمات القراءة تحديث أنظمتها، وما التأثير المحدد لتغيير حقل رسوم الأولوية؟
يجب على جميع الخدمات التي تجلب بيانات الكتل والمعاملات تحديث شيفرتها، وإلا فستعيد خطأً فور مواجهة معاملة v1. ويختلف موضع حقل رسوم الأولوية في v1 عن v0، لذا ستعرض البرمجيات القديمة عند القراءة «رسومًا صفرية»، حتى لو كان المستخدم قد دفع رسوم الأولوية، كما ستعرض المحافظ ومستكشفات سلاسل الكتل معلومات غير دقيقة عن الرسوم إذا لم تُحدّث.
