فريق سولانا الأساسي “أنزا” ينشر المعاملة V1 (SIMD-0385) على الشبكة الرئيسية.
لم يفهم كثيرون ما الذي تعنيه هذه الخطوة بالضبط.
في السابق كانت هناك حد أقصى قدره 1232 بايت على معاملة سولانا الفردية الواحدة $SOL . عندما يقوم المطورون ببناء منطق معقد عليها، يصبح الأمر ككتابة كود على طابع بريد. بمجرد دخول مدفوعات الخصوصية مع إثباتات ZK، أو التواقيعات المتعددة المعقدة على مستوى المؤسسات باستخدام BLS، أو تجميعات التصفية المتقدمة في DeFi متعددة المسارات، تتجاوز كمية بيانات المعاملة الحد في غضون دقائق.
الحل الوحيد سابقًا كان تقسيمها إلى عدة معاملات فرعية متتالية وإرسالها.
لكن ذلك يسبب خطرًا قاتلًا: عند الإرسال، إذا تعثرت خطوة ما أو فشلت في المنتصف، تنفصل الحالات قبلها وبعدها. قد يقوم مُحقِّقو المراجحة بإدخال “إبرة” مباشرة عندما يتم تصفية المعاملة الأولى لديك لكن الثانية لم تلتحق بعد، فيتحمل المستخدم خسارة كاملة.
الآن يمكن حزم هذه الإجراءات التشفيرية المعقدة ومنطق السلاسل المتعدد داخل معاملة ذرّية واحدة. إما أن تمر كلها أو تُلغى كلها، دون أي مساحة يمكن أن يتم فيها إدخال شيء بين المراحل أو “الاعتراض” أو “الاختراق” في المنتصف. هذا لا يلغي فقط النفقات التكرارية لتنسيق عدة معاملات، بل يقلل أيضًا التفاعلات التي كانت شديدة التعقيد إلى إجراء توقيع واحد.
والأكثر إثارة للاهتمام هو تعديل جدولة الموارد. نقل “أنزا” وحدات الحساب (CU)، والرسوم ذات الأولوية، وبيانات الحساب وغيرها من الإعدادات مباشرة إلى رأس المعاملة. لا يحتاج عقد RPC ولا المُحققون (الـ validators) إلى قلب المقطع بالكامل (payload) كما في السابق لاستخراج أولوية المعاملة ومعدل الرسوم؛ بل يمكن إجراء فحص مسبق وتوزيع للموارد في الرأس مباشرة. ستتحسن كفاءة ترتيب المعاملات عالية التردد واصطفاف MEV على مستوى الطبقة الفيزيائية.
ورغم أنه بسبب تكامل أدوات النظام البيئي مع الاختبارات، تم تأجيل وقت الإطلاق إلى Epoch رقم 1035 بدلًا من الموعد، إلا أن ذلك يوضح أن الفريق يضع أساس أمان الشبكة الرئيسية أولًا—ويفضل التأخير على اغتنام لحظة تشغيل العقدة على حساب السلامة.
بالطبع، زيادة المساحة بمقدار 3 أضعاف لا تعني أن تطبيقات الطرف الآخر يمكنها الاستفادة من المكاسب دون تفكير. التقدم في تكييف البنية التحتية، وضغط التحميل على عقد RPC، وما إذا كان مطورو DApp يمكنهم فعلًا تجسيد منطق ZK ومنطق المؤسسات على أرض الواقع—هي العوامل التي تحدد إلى أي مدى يمكن أن يعمل هذا التحديث بكفاءة.
هذه ليست ميزة إيجابية واضحة يمكن أن تدفع السعر للارتفاع مباشرة، لكن بمجرد فتح التسامح في الطبقة التقنية أمام المعمارية المعقدة، فإن قنوات إدخال التطبيقات عالية القيمة ورؤوس الأموال المؤسسية هي التي تُفتح فعليًا.
#solana交易v1上线主网
لم يفهم كثيرون ما الذي تعنيه هذه الخطوة بالضبط.
في السابق كانت هناك حد أقصى قدره 1232 بايت على معاملة سولانا الفردية الواحدة $SOL . عندما يقوم المطورون ببناء منطق معقد عليها، يصبح الأمر ككتابة كود على طابع بريد. بمجرد دخول مدفوعات الخصوصية مع إثباتات ZK، أو التواقيعات المتعددة المعقدة على مستوى المؤسسات باستخدام BLS، أو تجميعات التصفية المتقدمة في DeFi متعددة المسارات، تتجاوز كمية بيانات المعاملة الحد في غضون دقائق.
الحل الوحيد سابقًا كان تقسيمها إلى عدة معاملات فرعية متتالية وإرسالها.
لكن ذلك يسبب خطرًا قاتلًا: عند الإرسال، إذا تعثرت خطوة ما أو فشلت في المنتصف، تنفصل الحالات قبلها وبعدها. قد يقوم مُحقِّقو المراجحة بإدخال “إبرة” مباشرة عندما يتم تصفية المعاملة الأولى لديك لكن الثانية لم تلتحق بعد، فيتحمل المستخدم خسارة كاملة.
الآن يمكن حزم هذه الإجراءات التشفيرية المعقدة ومنطق السلاسل المتعدد داخل معاملة ذرّية واحدة. إما أن تمر كلها أو تُلغى كلها، دون أي مساحة يمكن أن يتم فيها إدخال شيء بين المراحل أو “الاعتراض” أو “الاختراق” في المنتصف. هذا لا يلغي فقط النفقات التكرارية لتنسيق عدة معاملات، بل يقلل أيضًا التفاعلات التي كانت شديدة التعقيد إلى إجراء توقيع واحد.
والأكثر إثارة للاهتمام هو تعديل جدولة الموارد. نقل “أنزا” وحدات الحساب (CU)، والرسوم ذات الأولوية، وبيانات الحساب وغيرها من الإعدادات مباشرة إلى رأس المعاملة. لا يحتاج عقد RPC ولا المُحققون (الـ validators) إلى قلب المقطع بالكامل (payload) كما في السابق لاستخراج أولوية المعاملة ومعدل الرسوم؛ بل يمكن إجراء فحص مسبق وتوزيع للموارد في الرأس مباشرة. ستتحسن كفاءة ترتيب المعاملات عالية التردد واصطفاف MEV على مستوى الطبقة الفيزيائية.
ورغم أنه بسبب تكامل أدوات النظام البيئي مع الاختبارات، تم تأجيل وقت الإطلاق إلى Epoch رقم 1035 بدلًا من الموعد، إلا أن ذلك يوضح أن الفريق يضع أساس أمان الشبكة الرئيسية أولًا—ويفضل التأخير على اغتنام لحظة تشغيل العقدة على حساب السلامة.
بالطبع، زيادة المساحة بمقدار 3 أضعاف لا تعني أن تطبيقات الطرف الآخر يمكنها الاستفادة من المكاسب دون تفكير. التقدم في تكييف البنية التحتية، وضغط التحميل على عقد RPC، وما إذا كان مطورو DApp يمكنهم فعلًا تجسيد منطق ZK ومنطق المؤسسات على أرض الواقع—هي العوامل التي تحدد إلى أي مدى يمكن أن يعمل هذا التحديث بكفاءة.
هذه ليست ميزة إيجابية واضحة يمكن أن تدفع السعر للارتفاع مباشرة، لكن بمجرد فتح التسامح في الطبقة التقنية أمام المعمارية المعقدة، فإن قنوات إدخال التطبيقات عالية القيمة ورؤوس الأموال المؤسسية هي التي تُفتح فعليًا.
#solana交易v1上线主网
