كثيرون ينتقدون #dusk EVM باعتباره "عودة إلى الوراء"، لكنني أرى أن الأمر على العكس تمامًا: الفريق أخيرًا فهم شيئًا واحدًا؛ التوافق ليس تنازلًا، بل هو التحكم في التكاليف.
إنشاء بيئة تنفيذ جديدة بالكامل قد لا يعني تقنيًا أنها أقل من الإيثيريوم، لكن الثمن هو أن كل المرافق المساندة يجب أن تنمو مرة أخرى من الصفر—شركات التدقيق تحتاج إلى تعلم لغة جديدة لإصدار التقارير، وفِرق المحافظ يجب أن تعيد كتابة منطق التوقيع، وخدمات الفهرسة عليها أن تتكيف من جديد. في النهاية، ستُحوَّل هذه التكاليف إلى المؤسسات التي تختار بالفعل الرفع على السلسلة، وعندما تُجري المؤسسات اختيارات تقنية، غالبًا ما ينظرون أولًا إلى "هل يمكن لفريقي الحالي البدء مباشرة؟" وليس إلى "مدى أناقة تصميم هذه اللغة".
@Dusk EVM ذكي لأنه يفصل بين طبقة التنفيذ والقدرات الأساسية: يظل المطورون يستخدمون أدواتهم المألوفة لنشر العقود، لكن إذا رغبوا في ذلك يمكنهم استدعاء إمكانات التسوية السرّية الأصلية والتحقق من الامتثال في الطبقة السفلية. كأنه يعطي المطورين خيارًا، لا يفرض عليهم طريقًا واحدًا حتى النهاية. وبالنسبة للفرق التي كانت تعمل بالفعل على التحويلات الرمزية على الإيثيريوم، فمن الناحية النظرية يمكنها تقليل إعادة قلب الكثير من الأكواد، وربط منطق التسوية مباشرة بسلسلة أُعدت أصلًا لحالات الاستخدام الخاضعة للرقابة.
لكنني لن أُعجب به درجة أعلى لأن هذا التصميم موجود. إضافة طبقة توافق إضافية تعني افتراض ثقة إضافي، وفي أماكن مثل التواصل عبر الطبقات وتزامن الحالة، لا تقل الحوادث التاريخية سوءًا عما حدث في ثغرات العقود. والمخاطر الأكثر واقعية هي أنه إذا قام معظم المطورين بنقل المشاريع القديمة كما هي دون تغيير—بسبب رغبتهم في راحة نظام EVM البيئي—فإن قدرات التسوية السرّية، وهي الاختلاف الحقيقي، ستُترك جانبًا، و$DUSK EVM لن يكون مختلفًا كثيرًا عن سلسلة جانبية عادية متوافقة مع EVM.
لذلك لا أولي اهتمامًا كبيرًا لرقم نشر العقود الذي يصنع ضجة؛ ما أريد معرفته هو: من بين هذه العقود، كم منها استعمل بالفعل وحدات الخصوصية والامتثال الأصليتين؟ إذا لم يرتفع هذا النسب، فإن قصة التميز التي يرويها DuskEVM لن تتجاوز كونها مجرد خيار، ولن تتحول إلى حقيقة.
إنشاء بيئة تنفيذ جديدة بالكامل قد لا يعني تقنيًا أنها أقل من الإيثيريوم، لكن الثمن هو أن كل المرافق المساندة يجب أن تنمو مرة أخرى من الصفر—شركات التدقيق تحتاج إلى تعلم لغة جديدة لإصدار التقارير، وفِرق المحافظ يجب أن تعيد كتابة منطق التوقيع، وخدمات الفهرسة عليها أن تتكيف من جديد. في النهاية، ستُحوَّل هذه التكاليف إلى المؤسسات التي تختار بالفعل الرفع على السلسلة، وعندما تُجري المؤسسات اختيارات تقنية، غالبًا ما ينظرون أولًا إلى "هل يمكن لفريقي الحالي البدء مباشرة؟" وليس إلى "مدى أناقة تصميم هذه اللغة".
@Dusk EVM ذكي لأنه يفصل بين طبقة التنفيذ والقدرات الأساسية: يظل المطورون يستخدمون أدواتهم المألوفة لنشر العقود، لكن إذا رغبوا في ذلك يمكنهم استدعاء إمكانات التسوية السرّية الأصلية والتحقق من الامتثال في الطبقة السفلية. كأنه يعطي المطورين خيارًا، لا يفرض عليهم طريقًا واحدًا حتى النهاية. وبالنسبة للفرق التي كانت تعمل بالفعل على التحويلات الرمزية على الإيثيريوم، فمن الناحية النظرية يمكنها تقليل إعادة قلب الكثير من الأكواد، وربط منطق التسوية مباشرة بسلسلة أُعدت أصلًا لحالات الاستخدام الخاضعة للرقابة.
لكنني لن أُعجب به درجة أعلى لأن هذا التصميم موجود. إضافة طبقة توافق إضافية تعني افتراض ثقة إضافي، وفي أماكن مثل التواصل عبر الطبقات وتزامن الحالة، لا تقل الحوادث التاريخية سوءًا عما حدث في ثغرات العقود. والمخاطر الأكثر واقعية هي أنه إذا قام معظم المطورين بنقل المشاريع القديمة كما هي دون تغيير—بسبب رغبتهم في راحة نظام EVM البيئي—فإن قدرات التسوية السرّية، وهي الاختلاف الحقيقي، ستُترك جانبًا، و$DUSK EVM لن يكون مختلفًا كثيرًا عن سلسلة جانبية عادية متوافقة مع EVM.
لذلك لا أولي اهتمامًا كبيرًا لرقم نشر العقود الذي يصنع ضجة؛ ما أريد معرفته هو: من بين هذه العقود، كم منها استعمل بالفعل وحدات الخصوصية والامتثال الأصليتين؟ إذا لم يرتفع هذا النسب، فإن قصة التميز التي يرويها DuskEVM لن تتجاوز كونها مجرد خيار، ولن تتحول إلى حقيقة.