كيف تعمل المعاملات على سولانا؟

نظرًا لأن رسومًا تُدفع عند تنفيذ كل معاملة، من المفيد أن نفهم كيفية عمل المعاملات. تتكون المعاملة من ثلاثة أجزاء:

تعليمة واحدة أو أكثر
مصفوفة من الحسابات للقراءة منها أو الكتابة إليها
توقيع واحد أو أكثر
تجزئة كتلة حديثة أو nonce

التعليمة هي أصغر وحدة منطق تنفيذي على سولانا. التعليمات هي طلبات لتحديث الحالة العامة لسولانا. تستدعي التعليمات البرامج التي تُجري طلبات إلى وقت تشغيل سولانا لتحديث الحالة (على سبيل المثال، استدعاء Token Program لنقل الرموز من حسابك إلى حساب آخر). يمكنك التفكير في التعليمة كاستدعاء دالة في عقد ذكي على إيثيريوم.

من الفروق الجوهرية بين إيثيريوم وسولانا هو عدد استدعاءات الدوال في معاملة واحدة بسبب تعدد التعليمات. يُفيد وجود تعليمات متعددة في المعاملة الواحدة المطورين، إذ لا يحتاجون إلى إنشاء عقود ذكية مخصصة لربط الدوال في معاملة واحدة. يمكن أن تكون كل تعليمة استدعاءً منفصلًا للدالة، يُنفَّذ بالترتيب ضمن المعاملة. المعاملات ذرية، مما يعني أنه إذا فشلت أي تعليمة فستفشل المعاملة بأكملها، وستدفع رسوم المعاملة فحسب. هذا مشابه لفشل المعاملة بسبب عدم ضبط الانزلاق الصحيح على إيثيريوم.

فرق رئيسي آخر ينبغي تذكره هو استخدام تجزئة كتلة حديثة بدلًا من nonce تصاعدي للمعاملات. عندما تريد محفظة إجراء معاملة، يتم سحب تجزئة كتلة حديثة من الشبكة لإنشاء معاملة صالحة. تجعل هذه التجزئة الحديثة المعاملة صالحة فقط لمدة 150 كتلة بعد استردادها، مما يمنع تنفيذ توقيعات المعاملات طويلة الأمد في تاريخ لاحق.

Cross-Program Invocation (CPI)

Cross-Program Invocation (CPI) هو عندما يستدعي برنامج سولانا تعليمةً في برنامج آخر أثناء تنفيذ المعاملة الأصلية. يُعدّ CPI الطريقة الرئيسية التي تتكامل بها برامج سولانا مع بعضها، غير أن نموذج الحسابات يُغير طريقة تصميم شجرة الاستدعاء: يجب أن تتضمن المعاملة كل حساب سيقرأ منه أو يكتب إليه سلسلة CPI الكاملة قبل بدء التنفيذ.

يرث المُستدعَى فقط صلاحيات التوقيع والكتابة التي حصل عليها المُستدعِي، ويستهلك المُستدعَى من نفس ميزانية الحوسبة للمعاملة. استخدم invoke عندما يكون جميع الموقّعين المطلوبين قد وقّعوا المعاملة الأصلية. استخدم invoke_signed عندما يحتاج البرنامج المُستدعِي إلى التوقيع عن أحد Program Derived Addresses التابعة له باستخدام بذور التوقيع.

مستويات التأكيد

يمكن لقراءات RPC والاشتراكات ومنطق تأكيد المعاملات اختيار مستوى commitment. هذا هو تعادل سولانا لقرار عدد تأكيدات كتل إيثيريوم الواجب انتظارها، إلا أن المستويات هنا صريحة:

processed: أحدث عرض معالج للعقدة. استخدمه فقط لواجهات المستخدم التفاؤلية أو التدفقات التي تتحمل التراجع.
confirmed: كتلة صوّت عليها أغلبية كبيرة من الحصة. استخدمه كخيار افتراضي لمعظم تأكيدات الإنتاج وحالة المعاملات الموجهة للمستخدم.
finalized: أقوى حالة تأكيد. استخدمه قبل الإجراءات خارج السلسلة غير القابلة للعكس كمدفوعات العملات الورقية، أو شحن البضائع، أو سجلات التسوية النهائية.

إذا كانت طريقة RPC تقبل commitment ولم تحدده، فالافتراضي عادةً هو finalized. ينبغي للعملاء في بيئة الإنتاج تحديد commitment صراحةً حتى تكون زمن استجابة واجهة المستخدم وسلوك المُفهرِس وسياسة التسوية مقصودة.