ملخص؛ DR: النموذج الحالي لترقية برامج سولانا هو كارثة. أخطر شيء في كتابة كود العقود الذكية هو أن نماذج بيانات البرنامج تكون فعليا مقفلة بعد النشر. في البرمجيات البرمجية التقليدية، يتم فصل واجهة برمجة التطبيقات الخاصة بالعميل عن الخلفية. يمكنك تغيير مخطط الواجهة الخلفية بشكل غير مرئي أو إضافة ترحيلات إلى قاعدة البيانات. في برمجة سولانا، يمكنك محاولة تأمين عقد من خلال: - إضافة حشو الهيكل والأمل في وجود عدد كاف من البتات الفارغة في بيانات الحساب للتغييرات المستقبلية - مطالبة المستخدمين بالتوقيع يدويا لنقل حالة التطبيق (تجربة مستخدم سيئة للغاية) - تنفيذ إجراءات إدارية على مستوى التطبيق لترحيل المخططات لاحظ أن كل ما سبق لديه القدرة على كسر قابلية التركيب على مستوى الآلة الافتراضية. كما أنها تتطلب منطقا معقدا وعرضة للأخطاء لتنفيذها بأمان. لا يقتصر الأمر على إدخال مخاطر البيانات المنطقية، بل أيضا مخاطر إدارة المفاتيح. أحد الحجج هو ألا تغير الكود بعد النشر. ففي النهاية، الإطار الحالي يجعل من الصعب للغاية تعديل تنسيقات البيانات الحالية بأمان. ومع ذلك، حتى لو كان الثبات مرغوبا، فمن السذاجة والتهور الاعتقاد بأنه لا توجد أخطاء كارثية يجب إصلاحها أو ميزات حرجة لإضافتها في المستقبل (بعضها قد يتطلب تغييرات في الأسلاك). الشركات التي تبني على هذه السلسلة مضطرة للاختيار بين الأمان، والسرعة، والجودة. اليوم، الأدوات التي تمكن من صيانة وتطوير عقد ذكي معقد بما فيه الكفاية غير موجودة. إليك بعض الميزات التي كنت سأفكر في تضمينها لو كنت أبني هذه البيئة من المبادئ الأساسية: - يجب أن تكون هناك واجهات برمجة تطبيقات منفصلة في الجهاز الافتراضي لقراءة وكتابة بيانات الحساب. يتيح ذلك تغييرات المخطط دون كسر تنسيق السلك لكل من المستهلكين على السلسلة وخارجها. - يجب أن توجد بعض وظائف العقود الذكية الإدارية (الاختيارية) على مستوى النظام، وليس على مستوى التطبيق. - عند الترقية التنفيذية، يجب أن يكون هناك في الوقت نفسه ترحيل ذري اختياري للحسابات المملوكة لذلك البرنامج. حتى لو كان الهدف هو الثبات، فإن بناء أدوات على مستوى النظام لتمكين تحديثات البرمجيات الآمنة أمر بالغ الأهمية لتطبيقات المستهلكين ذات الحالة المتطورة. النظام الحالي هش جدا لدرجة أن أفضل نصيحة لهؤلاء المطورين هي ألا تلمس المخططات على السلسلة إلا إذا كانوا يعرفون حقا ما يفعلونه.