#dusk $DUSK أنا خلال اليومين الماضيين أتصفح مستودع GitHub الخاص بـ Dusk، ووجدت وثيقة لم يتم التوسع فيها كثيرًا ولكنها تصميم شديد الأهمية: نموذج عزل الذاكرة في Piecrust VM.
معظم آلات تنفيذ العقود الذكية تستخدم ذاكرة مشتركة؛ وتتنقل البيانات بين العقود عبر استدعاءات الرسائل. الإيجابيات هي المرونة، لكن العيب هو أن خطأ (bug) في عقد واحد قد يلوث مساحة الذاكرة الخاصة بعقود أخرى. اختار Piecrust VM طريقًا مختلفًا—فكل مثيل لعقد لديه مساحة ذاكرة خطية مستقلة به، ولا يمكن للعقود قراءة ذاكرة بعضها البعض أو كتابتها مباشرة؛ بل يجب تمرير البيانات عبر واجهات ABI محددة لنقل بيانات مُسلسلة (serialized).
مستوى العزل هذا، للتشبيه، أقرب إلى sandbox الخاصة بـ WebAssembly وليس إلى shared state الخاص بـ EVM. وبالنسبة للمشهد المالي المنضبط الذي تستهدفه Dusk، فهذا التصميم مناسب جدًا: خطأ في عقد ترميز ورقة مالية (security token) لا يؤدي إلى تسريب أرصدة العملاء في عقد دفع مجاور، ويمكن أثناء عمليات التدقيق التحقق من كل عقد على حدة دون القلق بشأن تدفقات البيانات الضمنية عبر العقود.
تفصيل آخر لفت انتباهي هو طريقة احتساب gas في Piecrust. لا يحتسب مثل EVM على أساس opcode واحدة تلو الأخرى، بل يحسب وفق كلفة تنفيذ تعليمات wasm مع وزن مختلف. تكاليف gas الخاصة بعمليات الجمع والطرح ليست مثل تكاليف الضرب والقسمة؛ كما أن تكاليف قراءة/كتابة الذاكرة ليست مثل تكاليف العمليات الحسابية. من الناحية النظرية، تمنح هذه الدقة المطورين القدرة على كتابة عقود أكثر كفاءة—لأنهم يعرفون ما هي العمليات المكلفة فيتجنبونها.
بالطبع، هذا يعني أيضًا أن تقدير gas يصبح أكثر تعقيدًا. تقدير gas في EVM قد تم تلميعه بالفعل عبر سلسلة الأدوات (toolchain) وأصبح ناضجًا جدًا، بينما ما زال في Piecrust لا يوجد profiler ناضج. لكن الاتجاه صحيح: مقابل قياس أكثر دقة نحصل على تنفيذ أكثر كفاءة.@Dusk
معظم آلات تنفيذ العقود الذكية تستخدم ذاكرة مشتركة؛ وتتنقل البيانات بين العقود عبر استدعاءات الرسائل. الإيجابيات هي المرونة، لكن العيب هو أن خطأ (bug) في عقد واحد قد يلوث مساحة الذاكرة الخاصة بعقود أخرى. اختار Piecrust VM طريقًا مختلفًا—فكل مثيل لعقد لديه مساحة ذاكرة خطية مستقلة به، ولا يمكن للعقود قراءة ذاكرة بعضها البعض أو كتابتها مباشرة؛ بل يجب تمرير البيانات عبر واجهات ABI محددة لنقل بيانات مُسلسلة (serialized).
مستوى العزل هذا، للتشبيه، أقرب إلى sandbox الخاصة بـ WebAssembly وليس إلى shared state الخاص بـ EVM. وبالنسبة للمشهد المالي المنضبط الذي تستهدفه Dusk، فهذا التصميم مناسب جدًا: خطأ في عقد ترميز ورقة مالية (security token) لا يؤدي إلى تسريب أرصدة العملاء في عقد دفع مجاور، ويمكن أثناء عمليات التدقيق التحقق من كل عقد على حدة دون القلق بشأن تدفقات البيانات الضمنية عبر العقود.
تفصيل آخر لفت انتباهي هو طريقة احتساب gas في Piecrust. لا يحتسب مثل EVM على أساس opcode واحدة تلو الأخرى، بل يحسب وفق كلفة تنفيذ تعليمات wasm مع وزن مختلف. تكاليف gas الخاصة بعمليات الجمع والطرح ليست مثل تكاليف الضرب والقسمة؛ كما أن تكاليف قراءة/كتابة الذاكرة ليست مثل تكاليف العمليات الحسابية. من الناحية النظرية، تمنح هذه الدقة المطورين القدرة على كتابة عقود أكثر كفاءة—لأنهم يعرفون ما هي العمليات المكلفة فيتجنبونها.
بالطبع، هذا يعني أيضًا أن تقدير gas يصبح أكثر تعقيدًا. تقدير gas في EVM قد تم تلميعه بالفعل عبر سلسلة الأدوات (toolchain) وأصبح ناضجًا جدًا، بينما ما زال في Piecrust لا يوجد profiler ناضج. لكن الاتجاه صحيح: مقابل قياس أكثر دقة نحصل على تنفيذ أكثر كفاءة.@Dusk