#dusk $DUSK كثيرون يعتبرون التوافق مع EVM بمثابة "تصريح عبور" لـ "ترحيل بنقرة واحدة"، ظنًا منهم أن وصول المطورين يعني أن كل شيء سيكون على ما يرام. مؤخرًا، قمتُ بالاطلاع على وثائق شبكة الاختبار الخاصة بـ DuskEVM وطبّقتُ خطوات النشر كاملة، واكتشفت أن المشكلة أعقد مما كنت أتصور: فالتوافق هو مجرد البداية، أما التحدي الحقيقي فيظهر بعد عملية الترحيل، وهو أيضًا تحدٍّ في الاتجاهين.
يدعم DuskEVM Solidity القياسي وسلسلة أدوات Hardhat. وبالنسبة لمطوري Ethereum، فهذا يعني إمكانية نشر العقود على Dusk باستخدام أدواتهم المألوفة. بالنسبة إلى $DUSK ، فهذا يوسّع حوض التطبيقات المحتمل من الصفر ليشمل النظام البيئي لـ EVM بأكمله، ويخفض عتبة التطوير بشكل كبير. لكن ترحيل بروتوكول DeFi ليس مجرد نسخ/لصق: فهناك اختلاف في نموذج الغاز، واختلاف في زمن كتل الشبكة، وكذلك منطق تأكيد نهائية المعاملة (finality) أيضًا. والأهم من ذلك، فإن طبقة الخصوصية في Dusk (Phoenix) والطبقة العامة (Moonlight) تعملان جنبًا إلى جنب بنظام مزدوج. العقود الذكية الأصلية على Ethereum لا تدرك هذا النموذج الخاص بالخصوصية افتراضيًا، ناهيك عن استدعاء ميزات الخصوصية بشكل فعّال.
هنا تكمن العتبة الحقيقية. فإذا كان لدى المطور عقد مكتوب على Ethereum، فسيحتاج على Dusk إلى إعادة التفكير في أي البيانات ينبغي أن تمر عبر القناة العامة وأيها ينبغي أن تمر عبر طبقة الخصوصية. إن لم يتم هذا التكييف، فذلك يعني تعطيل أهم قدرة تميّز Dusk؛ وستتحول Dusk إلى مجرد سلسلة EVM عادية لا تختلف كثيرًا عن غيرها. لكن إن كان التكييف عميقًا جدًا، فقد تصبح قابلية ترحيل العقد مرتبطة ارتباطًا وثيقًا ببنية الخصوصية الفريدة في Dusk، وسيتخوف الفريق من الانغلاق داخل نظام بيئي واحد، مما يضعهم في موقف حرج من حيث التقدم أو التراجع.
في المرحلة التالية لن أركز على عدد عقود Demo التي تم نشرها على شبكة الاختبار. ما يستحق الانتباه فعلًا هو عدد البروتوكولات التي تعمل حقًا بنمط الخصوصية + العام المزدوج، ومقارنة استهلاك الغاز لعقود Solidity على Dusk، وما إذا كانت هناك فرق مستعدة لتطوير أصلي على Dusk بدل الاكتفاء بعمليات النقل السريعة. نجاح استراتيجية Dusk لـ EVM لا يعتمد على مقدار كود التوافق فحسب، بل يعتمد على عدد التطبيقات التي تستخدم فعليًا قدرات الخصوصية الفريدة في Dusk. برأيك، ما أكبر تحدٍ لسلاسل EVM المتوافقة: جذب المطورين أم جعل المطورين يبقون؟
#dusk @Dusk $DUSK
يدعم DuskEVM Solidity القياسي وسلسلة أدوات Hardhat. وبالنسبة لمطوري Ethereum، فهذا يعني إمكانية نشر العقود على Dusk باستخدام أدواتهم المألوفة. بالنسبة إلى $DUSK ، فهذا يوسّع حوض التطبيقات المحتمل من الصفر ليشمل النظام البيئي لـ EVM بأكمله، ويخفض عتبة التطوير بشكل كبير. لكن ترحيل بروتوكول DeFi ليس مجرد نسخ/لصق: فهناك اختلاف في نموذج الغاز، واختلاف في زمن كتل الشبكة، وكذلك منطق تأكيد نهائية المعاملة (finality) أيضًا. والأهم من ذلك، فإن طبقة الخصوصية في Dusk (Phoenix) والطبقة العامة (Moonlight) تعملان جنبًا إلى جنب بنظام مزدوج. العقود الذكية الأصلية على Ethereum لا تدرك هذا النموذج الخاص بالخصوصية افتراضيًا، ناهيك عن استدعاء ميزات الخصوصية بشكل فعّال.
هنا تكمن العتبة الحقيقية. فإذا كان لدى المطور عقد مكتوب على Ethereum، فسيحتاج على Dusk إلى إعادة التفكير في أي البيانات ينبغي أن تمر عبر القناة العامة وأيها ينبغي أن تمر عبر طبقة الخصوصية. إن لم يتم هذا التكييف، فذلك يعني تعطيل أهم قدرة تميّز Dusk؛ وستتحول Dusk إلى مجرد سلسلة EVM عادية لا تختلف كثيرًا عن غيرها. لكن إن كان التكييف عميقًا جدًا، فقد تصبح قابلية ترحيل العقد مرتبطة ارتباطًا وثيقًا ببنية الخصوصية الفريدة في Dusk، وسيتخوف الفريق من الانغلاق داخل نظام بيئي واحد، مما يضعهم في موقف حرج من حيث التقدم أو التراجع.
في المرحلة التالية لن أركز على عدد عقود Demo التي تم نشرها على شبكة الاختبار. ما يستحق الانتباه فعلًا هو عدد البروتوكولات التي تعمل حقًا بنمط الخصوصية + العام المزدوج، ومقارنة استهلاك الغاز لعقود Solidity على Dusk، وما إذا كانت هناك فرق مستعدة لتطوير أصلي على Dusk بدل الاكتفاء بعمليات النقل السريعة. نجاح استراتيجية Dusk لـ EVM لا يعتمد على مقدار كود التوافق فحسب، بل يعتمد على عدد التطبيقات التي تستخدم فعليًا قدرات الخصوصية الفريدة في Dusk. برأيك، ما أكبر تحدٍ لسلاسل EVM المتوافقة: جذب المطورين أم جعل المطورين يبقون؟
#dusk @Dusk $DUSK
兼容好做，留存才难
0%
隐私功能可能被闲置
100%
开发者更看重生态规
0%
1 الأصوات • تمّ إغلاق التصويت