#dusk الجميع لديه خبرة كبيرة في بناء الإيثيريوم (#ETH ) أو Arbitrum وOptimism من نوع L2. كتابة عقود Solidity أمر سهل من حيث المبدأ، لكن ما إن يتطلب الأمر حسابات معقدة أو إثباتات المعرفة الصفرية (ZKP)، تصبح أداء آلة افتراضية إيثيريوم (EVM) بطيئًا جدًا كسيارة قديمة، وتصبح رسوم الغاز باهظة بشكل غير معقول؛ لكن إذا حاولنا من أجل الأداء تطوير لغة طبقة أساسية جديدة تمامًا، فلن يرغب المطورون والمستخدمون أساسًا في الانتقال، فتتبخر البيئة البيئية مباشرة.
اليوم راجعت تصميم @Dusk ($DUSK )، ولاحظت أن فكرته لحل هذه المشكلة مثيرة للاهتمام—حيث جعل نفسه مباشرةً مثل «قطعة ليغو» معيارية.
بشكل مبسط، يقسم الطبقة الأساسية إلى ثلاث أجزاء:
الطبقة الأساسية لـ «الدفتر الكبير الرئيسي وغرفة المقاصة» (DuskDS): مسؤولة تحديدًا عن تشغيل إجماع SA وتنفيذ تسوية البيانات. هذا يشبه الخادم الرئيسي في البنك؛ يهتم بالتحقق النهائي من أصول النظام وضمان الأمان، دون القيام بأعمال إضافية، مع توفير قابلية عالية جدًا لاستخدام البيانات وحتمية التسوية.
الـ«محرك السريع الأصلي» (DuskVM / Piecrust): آلة افتراضية أصلية تعمل بـ Rust وWASM، مخصصة لمعالجة إثباتات المعرفة الصفرية والحسابات الخصوصية ذات الصعوبة العالية. هذا يشبه إضافة بطاقة رسومات احترافية للنظام، فتكون معاملات ZK الخصوصية سريعة جدًا.
الـ«واجهة العامة لإيثيريوم» المستخدمة للبناء (DuskEVM): طبقة توافق مخصصة لمطوري نظام إيثيريوم البيئي. لا يحتاج المطورون إلى تعلم لغة جديدة؛ بل يمكنهم، باستخدام Hardhat وMetamask وأدواتهم الحالية، نقل التطبيقات التي تعمل على ETH كبديل مباشر، ثم يتم خصم رسوم الغاز باستخدام $DUSK .
هذا التصميم الذي يفصل طبقة التسوية عن طبقة التنفيذ أشبه بإدخال «تركيب وإزالة بلا ألم» للبيئة الضخمة لإيثيريوم إلى طبقة أساسية فائقة مزودة بمحرك تسريع خصوصية ZKP.
لكن بصراحة، فكرة التصميم الطبقي جميلة، غير أن التحدي الحقيقي هو الأمان في التفاعل بين الطبقات المتعددة. عندما تنتقل الأصول عبر طبقات بين DuskEVM والطبقة الأصلية للخصوصية، هل ستضاعف تعقيد المنطق؟ هل توجد ثغرات في العقود؟ هل يمكن للمستخدمين قبول زمن التأخير في التسويات بين الطبقات؟ هذه كلها اختبارات قاسية يجب اجتيازها قبل أن تزدهر البيئة على الشبكة الرئيسية. تواصلوا في قسم التعليقات!
اليوم راجعت تصميم @Dusk ($DUSK )، ولاحظت أن فكرته لحل هذه المشكلة مثيرة للاهتمام—حيث جعل نفسه مباشرةً مثل «قطعة ليغو» معيارية.
بشكل مبسط، يقسم الطبقة الأساسية إلى ثلاث أجزاء:
الطبقة الأساسية لـ «الدفتر الكبير الرئيسي وغرفة المقاصة» (DuskDS): مسؤولة تحديدًا عن تشغيل إجماع SA وتنفيذ تسوية البيانات. هذا يشبه الخادم الرئيسي في البنك؛ يهتم بالتحقق النهائي من أصول النظام وضمان الأمان، دون القيام بأعمال إضافية، مع توفير قابلية عالية جدًا لاستخدام البيانات وحتمية التسوية.
الـ«محرك السريع الأصلي» (DuskVM / Piecrust): آلة افتراضية أصلية تعمل بـ Rust وWASM، مخصصة لمعالجة إثباتات المعرفة الصفرية والحسابات الخصوصية ذات الصعوبة العالية. هذا يشبه إضافة بطاقة رسومات احترافية للنظام، فتكون معاملات ZK الخصوصية سريعة جدًا.
الـ«واجهة العامة لإيثيريوم» المستخدمة للبناء (DuskEVM): طبقة توافق مخصصة لمطوري نظام إيثيريوم البيئي. لا يحتاج المطورون إلى تعلم لغة جديدة؛ بل يمكنهم، باستخدام Hardhat وMetamask وأدواتهم الحالية، نقل التطبيقات التي تعمل على ETH كبديل مباشر، ثم يتم خصم رسوم الغاز باستخدام $DUSK .
هذا التصميم الذي يفصل طبقة التسوية عن طبقة التنفيذ أشبه بإدخال «تركيب وإزالة بلا ألم» للبيئة الضخمة لإيثيريوم إلى طبقة أساسية فائقة مزودة بمحرك تسريع خصوصية ZKP.
لكن بصراحة، فكرة التصميم الطبقي جميلة، غير أن التحدي الحقيقي هو الأمان في التفاعل بين الطبقات المتعددة. عندما تنتقل الأصول عبر طبقات بين DuskEVM والطبقة الأصلية للخصوصية، هل ستضاعف تعقيد المنطق؟ هل توجد ثغرات في العقود؟ هل يمكن للمستخدمين قبول زمن التأخير في التسويات بين الطبقات؟ هذه كلها اختبارات قاسية يجب اجتيازها قبل أن تزدهر البيئة على الشبكة الرئيسية. تواصلوا في قسم التعليقات!
