#dusk $DUSK @Dusk لم أفهم أمرًا واحدًا منذ البداية: لدى Dusk بيئة تشغيل للعقود الذكية الأصلية الخاصة بها، وهي مخصصة لتشغيل العقود المكتوبة بلغة Rust. وفي الوقت نفسه، أعدّت أيضًا طبقة تنفيذ متوافقة مع Ethereum، بحيث يمكن للمرء كتابة العقود باستخدام نفس لغة التطوير المعتادة لديه. وجود بيئتين يتم صيانتهما معًا يبدو كأنه يزيد عبء الصيانة على الفريق، ولذلك قررت في هذه المرة تحديدًا أن أفهم ما الذي تهدف إليه هذه الاختيارات.
بعد البحث في المصادر، فهمت أن الأمر يتعلق في الحقيقة بفئتين مختلفتين تمامًا من المطورين يجري الاهتمام بهما معًا. البيئة الأصلية تستهدف فرقًا راغبة في تعلم Rust مباشرة، وترغب في الحصول على القدرات الأعمق في البروتوكول (مثل التعامل مباشرةً مع مجموعة الحسابات المخفية المشفرة). من ناحية الأداء والمرونة، تكون أعلى، لكن عتبة الدخول مرتفعة أيضًا، كما أن عدد من يكتبون عقودًا ذكية بـ Rust في السوق أقل بكثير من أولئك الذين يكتبون بلغات نظام Ethereum. أما الطبقة المتوافقة مع Ethereum، فهدفها هو "الرصيد"؛ فهناك بالفعل عدد كبير من المطورين وعدة أدوات جاهزة مبنية حول نظام Ethereum البيئي. إذا لم تُوفّر Dusk مدخلًا متوافقًا، فلن يرغب معظم هؤلاء في إعادة تعلم سلسلة الأدوات الخاصة بالبيئة من الصفر من أجل سلسلة جديدة، وسيختارون بدلًا من ذلك التطوير في مكان آخر أكثر توافقًا.
كنت أظن في البداية أن هذا نوع من "أريد هذا وأريد ذاك"—محاولة إرضاء الطرفين معًا قد تؤدي إلى عدم الإتقان في كليهما. ثم راجعت توضيحات الجهة الرسمية حول定位 كل طبقة واكتشفت أن الأمر ليس كذلك على الإطلاق: لم تكن النية أن تكون وظيفتا الطبقتين متكافئتين بالكامل. فالطبقة الأصلية مخصصة للسيناريوهات على مستوى البروتوكول، حيث يتطلب الأمر ارتباطًا عميقًا بالخصوصية وقدرات التسوية. أما طبقة التوافق مع Ethereum فهي أكثر لاستخدامها كوسيلة للاتصال السريع بالنظام الخارجي وبالتطبيقات الجاهزة. وبهذه القسمة، لا يبدو أن هناك تكرارًا لصنع العجلة؛ بل أشبه بفتح أبواب مناسبة لاحتياجات مختلفة من الناس، وليس تنفيذ الأمر نفسه مرتين.
لكنني أيضًا لم أجد بيانات توزيع المطورين بشكل محدد، مثل النسبة التقريبية بين التطبيقات الفعلية المنشورة التي تسلك الطريق الأصلي وتلك التي تسلك طريق التوافق مع Ethereum. في هذه المرحلة لا توجد أرقام يمكن الاستناد إليها للتحقق. كل ما يمكن قوله هو أن فكرة تصميم هذه البنية منطقية، لكن بعد تطبيق هذه الرؤية على أرض الواقع، أيّ مسار سيتم استخدامه فعليًا سيظل يعتمد على عدد التطبيقات التي سيتم نشرها لاحقًا.
بعد البحث في المصادر، فهمت أن الأمر يتعلق في الحقيقة بفئتين مختلفتين تمامًا من المطورين يجري الاهتمام بهما معًا. البيئة الأصلية تستهدف فرقًا راغبة في تعلم Rust مباشرة، وترغب في الحصول على القدرات الأعمق في البروتوكول (مثل التعامل مباشرةً مع مجموعة الحسابات المخفية المشفرة). من ناحية الأداء والمرونة، تكون أعلى، لكن عتبة الدخول مرتفعة أيضًا، كما أن عدد من يكتبون عقودًا ذكية بـ Rust في السوق أقل بكثير من أولئك الذين يكتبون بلغات نظام Ethereum. أما الطبقة المتوافقة مع Ethereum، فهدفها هو "الرصيد"؛ فهناك بالفعل عدد كبير من المطورين وعدة أدوات جاهزة مبنية حول نظام Ethereum البيئي. إذا لم تُوفّر Dusk مدخلًا متوافقًا، فلن يرغب معظم هؤلاء في إعادة تعلم سلسلة الأدوات الخاصة بالبيئة من الصفر من أجل سلسلة جديدة، وسيختارون بدلًا من ذلك التطوير في مكان آخر أكثر توافقًا.
كنت أظن في البداية أن هذا نوع من "أريد هذا وأريد ذاك"—محاولة إرضاء الطرفين معًا قد تؤدي إلى عدم الإتقان في كليهما. ثم راجعت توضيحات الجهة الرسمية حول定位 كل طبقة واكتشفت أن الأمر ليس كذلك على الإطلاق: لم تكن النية أن تكون وظيفتا الطبقتين متكافئتين بالكامل. فالطبقة الأصلية مخصصة للسيناريوهات على مستوى البروتوكول، حيث يتطلب الأمر ارتباطًا عميقًا بالخصوصية وقدرات التسوية. أما طبقة التوافق مع Ethereum فهي أكثر لاستخدامها كوسيلة للاتصال السريع بالنظام الخارجي وبالتطبيقات الجاهزة. وبهذه القسمة، لا يبدو أن هناك تكرارًا لصنع العجلة؛ بل أشبه بفتح أبواب مناسبة لاحتياجات مختلفة من الناس، وليس تنفيذ الأمر نفسه مرتين.
لكنني أيضًا لم أجد بيانات توزيع المطورين بشكل محدد، مثل النسبة التقريبية بين التطبيقات الفعلية المنشورة التي تسلك الطريق الأصلي وتلك التي تسلك طريق التوافق مع Ethereum. في هذه المرحلة لا توجد أرقام يمكن الاستناد إليها للتحقق. كل ما يمكن قوله هو أن فكرة تصميم هذه البنية منطقية، لكن بعد تطبيق هذه الرؤية على أرض الواقع، أيّ مسار سيتم استخدامه فعليًا سيظل يعتمد على عدد التطبيقات التي سيتم نشرها لاحقًا.