Kiko奇科

#dusk $DUSK @Dusk

DuskEVM: إتاحة تطوير EVM لـ Dusk.

ماذا يحدث عندما تمنح L1 مصممة حول الخصوصية والبنية التحتية المالية أيضًا للمطورين إمكانية الوصول إلى نموذج تطوير Ethereum؟

هذه هي مهمة DuskEVM.

تصف وثائق Dusk DuskEVM بأنه بيئة تنفيذ متوافقة مع EVM يمكن للمطورين من خلالها البناء باستخدام Solidity أو Vyper مع الاستمرار في استخدام أدوات وبنية تحتية مألوفة في Ethereum. ويشمل ذلك محافظ JSON-RPC القياسية الخاصة بـ EVM وأطر التطوير مثل Foundry وHardhat وviem وethers.

التفصيل المعماري المهم هو أن DuskEVM لا يعمل كبيئة معزولة. تأتي التسوية وتوافر البيانات عبر DuskDS بينما يعمل DUSK كأصل الغاز الأصلي.

وهذا يخلق مسارًا عمليًا للتطوير لتطبيقات صُممت بالفعل حول منظومة EVM. وتحدد Dusk تحديدًا حالات استخدام مثل تطبيقات الأصول المُمَثَّلة (tokenized) وبروتوكولات DeFi وAMMs والإقراض.

وتكمن الأهمية بالتالي في أنها أقل ارتباطًا بمجرد إضافة التوافق مع EVM، وأكثر ارتباطًا بتقليل الفجوة في الأدوات بين ممارسات تطوير Ethereum الراسخة والبنية التحتية الأساسية لـ Dusk.

بالنسبة إلى @Dusk يمنح هذا المطورين نقطة دخول مألوفة دون الحاجة إلى التخلي عن البنية المعمارية الأصلية للشبكة.

هل يمكن أن يصبح التوافق مع EVM واحدًا من أهم الجسور بين البنية التحتية المتخصصة لـ Dusk والنظام البيئي الأوسع للمطورين؟

DuskVM مقابل DuskEVM: مساران للمطورين

هل يحتاج البلوك تشين إلى إجبار كل مطور على بيئة تنفيذ واحدة؟

تتخذ Dusk نهجًا مختلفًا عبر توفير مسارين لعقود ذكية، صُمما كلٌ منهما ليلائم نموذج تطوير مختلف.

DuskVM هو المسار الأصلي. يكتب المطورون العقود بلغة Rust ثم يقومون بتجميعها إلى WASM وتشغيلها مباشرةً على شبكة Dusk L1. يتيح ذلك للعقود وصولًا مباشرًا إلى نموذج تنفيذ Dusk L1 ونماذج المعاملات وبروتوكول العقود والقدرات التي تحتاج إلى أن تكون قريبة من الطبقة الأساسية، بما في ذلك ميزات الخصوصية ووظائف الإثباتات بالمعرفة الصفرية.

أما DuskEVM فيأخذ مسارًا يركز على التوافق. يمكن للمطورين استخدام Solidity أو Vyper إلى جانب محافظ EVM ومكتبات وأدوات مألوفة. يتم توفير التسوية وتوافر البيانات عبر DuskDS بينما يعمل DUSK كرمز الغاز الأصلي.

وعليه، فإن الفارق لا يتعلق بكون أحد البيئتين أفضل بقدر ما يتعلق بمواءمة البنية مع متطلبات التطبيق. يفضل DuskVM التنفيذ المباشر على L1 والقدرات الأصلية لدى Dusk. أما DuskEVM فيخفض عتبة الدخول أمام المطورين الذين يعملون بالفعل ضمن منظومة Ethereum.

بالنسبة إلى Dusk، فإن توفير المسارين يخلق توازنًا مثيرًا للاهتمام بين الوظائف الأصلية ووضوح تجربة المطورين.

هل يمكن أن يكون دعم التنفيذ الأصلي والتوافق مع EVM استراتيجية أقوى للمطورين بدلًا من فرض بيئة موحدة واحدة؟

$DUSK

#dusk @Dusk

علّق على فكرتك

الاستثمار بالـ Dusk: كيف يؤمّن DUSK الشبكة.

ما الذي يساهم به الاستيكينغ فعلًا في بلوكتشين، بخلاف جني المكافآت؟

في Dusk، يرتبط الاستيكينغ مباشرةً بالإجماع. يقوم مقدمو الخدمة (Provisioners) باستيكينغ DUSK ويشاركون في عملية اقتراح والتحقق من الكتل. يمكن للمقدمي الخدمات النشطين كسب مكافآت من انبعاثات التوكن ورسوم المعاملات، ما يجعل الاستيكينغ جزءًا من آلية أمن الشبكة وليس منتج عائد منفصل.

تُعد عملية الاختيار أيضًا مهمة. يقوم التعيين الحتمي (deterministic sortition) في Dusk باختيار مولّدي الكتل وأعضاء لجنة التصويت عبر عملية تُوزن حسب الاستيكينغ. صُمم هذا النظام بحيث تكون وتيرة الاختيار متناسبةً مع استيكينغ مقدم الخدمة، مع البقاء قابلة لإعادة الإنتاج وغير قابلة للتنبؤ مسبقًا.

بعد ذلك ينتقل الإجماع إلى التحقق من الاقتراح والمصادقة عليه. يقترح مقدم الخدمة المختار كتلة مرشحة، فتقوم لجنة بتقييمها، ثم تؤكد لجنة أخرى نتيجة التحقق. يمكن للغالبية العظمى من الأصوات الصحيحة أن تُنتج نتيجة ناجحة.

لكن المشاركة تحمل مسؤولية. تُميّز وثائق Dusk الحالية بين عقوبات لينة (soft) للمشاركة الفاشلة وعقوبات صارمة (hard) للسلوك الإجماعي غير الصحيح بشكل يمكن إثباته، بما في ذلك التوقيعات المتضاربة.

وهذا يخلق علاقة مهمة بين الرصيد الاقتصادي والمسؤولية الشبكية: فـ DUSK ليس مجرد توكنات مُقفلَة؛ بل يمنح المشاركين سببًا اقتصاديًا لتشغيل بنية تحتية للإجماع بشكل صحيح.

بالنسبة لـ @Dusk ، فإن الاستيكينغ هو بالتالي جزء من بنية الأمن نفسها.

$DUSK #dusk

هل يؤدي ربط الرصيد الاقتصادي مباشرةً بمسؤولية الإجماع إلى خلق حافز أقوى للمشاركة الموثوقة في الشبكة؟

الغسق: أكثر من مجرد رمز.

ما الذي يمنح رمزًا من سلسلة كتلة محلية قيمة عملية حقيقية بعيدًا عن مجرد تداوله؟

بالنسبة إلى Dusk DUSK يتم دمجه مباشرة في تشغيل الشبكة. يعرّفها التوثيق الرسمي باعتبارها الرمز الأصلي المستخدم لرسوم المعاملات والـ staking، ما يربط الأصل بكل من نشاط الشبكة والمشاركة في الإجماع.

كل معاملة تتطلب موارد شبكية وتعمل DUSK كأصل غاز (gas) تُستخدم للدفع مقابل تلك العمليات. ويشمل ذلك النشاط عبر بيئات تنفيذ Dusk، حيث تستخدم DuskEVM صراحةً DUSK كرمز الغاز الأصلي الخاص بها.

أما الدور الثاني فهو أكثر جوهرية حتى من ذلك: الـ staking.

تستخدم Dusk المُزوّدين (provisioners) للمشاركة في الإجماع، مع اختيار المُزوّدين النشطين لاقتراح الكتل والتحقق منها. ووفقًا للتوثيق الحالي يتطلب الـ staking المباشر تشغيل عقدة مُزوِّد (provisioner)، وتستند المكافآت إلى المشاركة في الإجماع والـ stake النشط.

كما تربط DUSK أجزاء مختلفة من منظومة النظام البيئي. يصف التوثيق الانتقال بين Dusk L1 و DuskEVM، بينما يمكن للمطورين البناء عبر DuskVM أو DuskEVM اعتمادًا على متطلبات التنفيذ والأدوات لديهم.

لذا فإن النقطة المثيرة للاهتمام ليست فقط أن DUSK هو الأصل الأصلي للشبكة. بل إن قيمته العملية مدمجة في الآليات التي تجعل الشبكة تعمل.

وبالنسبة إلى @Dusk ترتبط قيمة رمز DUSK العملية ارتباطًا وثيقًا بالبنية التحتية.

$DUSK #dusk

هل يصبح الرمز الأصلي أكثر معنى عندما تكون قيمته العملية غير قابلة للفصل عن عمليات الشبكة الأساسية؟

القلعة: الإفصاح الانتقائي للهوية الرقمية

غالبًا ما تخلق الهوية الرقمية خيارًا صعبًا: الكشف عن كل شيء لإثبات من أنت، أو الكشف عن القليل جدًا لدرجة لا تكفي لتلبية متطلبات التطبيق.

يعالج «ديـسك» هذه المشكلة عبر «القلعة» التي توصف في وثائقها بأنها طبقة هوية وإتاحة على الشبكة للإفصاح الانتقائي.

هذا التمييز مهم. الإفصاح الانتقائي ليس مجرد مسألة إبقاء معلومات الهوية خاصة. بل يتعلق بتصميم الوصول حول المعلومات التي يلزم بالفعل الإفصاح عنها من أجل تفاعل معيّن.

وينسجم ذلك طبيعيًا مع البنية الأوسع لـ«ديـسك». فالشبكة تميّز بالفعل بين الحسابات العامة والحسابات المحجوبة، مما يسمح بإجراء المعاملات بمستويات رؤية مختلفة. توسّع «القلعة» هذا التفكير ليشمل الهوية والإتاحة، وليس بيانات المعاملات وحدها.

كما تذكر وثائق «ديـسك» «هويات أصحاب السيادة ذاتيًا» لِـ«القلعة» على شبكة «ديـسك» باعتبارها ورقة بحثية مخصصة إلى جانب الأعمال التقنية المتعلقة بأنظمة المعرفة الصفرية وإثباتات إخفاء السمات.

ما يهمني هنا هو المبدأ المعماري: أن الهوية لا تحتاج بالضرورة إلى أن تصبح سجلًا عامًا دائمًا لمجرد أن المستخدم يحتاج إلى إثبات شيء ما.

بالنسبة لـ @Dusk ، يربط الإفصاح الانتقائي الخصوصية بالتحكم العملي في الوصول، وهو أمر ذو صلة خاصة عندما تتفاعل البنية التحتية لسلسلة الكتل مع التطبيقات التي تكون فيها الهوية والتفويض مهمة.

#dusk $DUSK

هل يمكن أن يصبح الإفصاح الانتقائي هو الطبقة المفقودة بين الخصوصية الرقمية ومتطلبات الهوية للأنظمة المالية المنظمة؟

الخصوصية دون فقدان الاستخدام العملي.

تصبح الخصوصية على سلسلة الكتل صعبة عندما يؤدي حماية المعلومات أيضًا إلى جعل النظام صعبًا في الاستخدام للتحقق أو التكامل.

تعالج Dusk هذه المشكلة من خلال جعل مستويات مختلفة لظهور المعاملات جزءًا من بنية الشبكة.

يوفر نموذج Moonlight الخاص بها معاملات عامة مبنية على الحسابات. يمكن أن تبقى عناوين الأرصدة ونشاط المعاملات شفافًا، وهو ما يكون مفيدًا عندما تكون هناك حاجة إلى وضوح الرؤية والتحقق المباشر.

أما Phoenix فتتبنى نهجًا معاكسًا عندما تكون السرية في المعاملات مهمة. فهي تستخدم معاملات مبنية على UTXO محمية، مبنية حول nullifiers للملاحظات وإثباتات المعرفة الصفرية. يمكن للشبكة التحقق من أن المعاملة صالحة دون كشف المرسل أو المستلم أو المبلغ المحوّل بشكل علني.

لكن الخصوصية في Phoenix ليست مجرد إخفاء المعلومات عن الجميع. يتضمن البروتوكول مفاتيح مشاهدة تسمح للمستخدمين بتحديد المعاملات الموجهة إليهم مع الحفاظ على سلطة الإنفاق محمية. كما يصف الورقة البيضاء كيف يمكن لمفاتيح المشاهدة تمكين المسح المفوض للمعاملات دون منح الجهة المفوضة القدرة على إنفاق الملاحظات.

هذه التفرقة مهمة، لأن خصوصية البنية التحتية المالية العملية لا تعني بالضرورة التخلي عن الوصول المتحكم للمعلومات.

لذلك، بالنسبة إلى @Dusk ، تُفهم الخصوصية بشكل أفضل كخاصية قابلة للتكوين للمعاملات، بدلًا من كونها عائقًا أمام قابلية الاستخدام.

$DUSK #dusk

هل يمكن أن تصبح الرؤية الانتقائية نموذجًا أكثر عملية لتمويل البلوك تشين مقارنةً بالاختيار بين الشفافية الكاملة واللاسرية الكاملة؟

ضوء القمر مقابل فينيكس: نموذجان للمعاملات.

من أكثر الخيارات إثارة للاهتمام في Dusk أن الخصوصية لا تُعامل على أنها قرار “إما نعم أو لا”.

بدلاً من ذلك، يوفّر Dusk نموذجين للمعاملات لهما أهداف مختلفة: Moonlight وPhoenix.
Moonlight هو نموذج الحساب العام في Dusk. كل حساب مرتبط بمفتاح عام، وتقوم الشبكة بالحفاظ على الرصيد وعداد المعاملات (transaction nonce). تتم المصادقة على المعاملات عبر التواقيع الرقمية، بينما تظل حالة الحساب شفافة للشبكة.
أمّا Phoenix فيتبع نهجاً مختلفاً جذرياً. فهو نموذج UTXO مُحصّن (shielded) حيث تُمثَّل UTXOs كملاحظات (notes) داخل شجرة Merkle. عندما تُنفق ملاحظة ما، يمنع مُعرِّف الإبطال (nullifier) الإنفاق المزدوج دون الكشف عن أي ملاحظة بعينها تم استهلاكها. تستخدم معاملات Phoenix إثباتات المعرفة الصفرية (zero knowledge proofs) حتى تتمكن الشبكة من التحقق من أن المعاملة تتبع قواعد البروتوكول دون كشف تفاصيل المعاملة الأساسية مباشرة.
تلك الفروق مهمة لأن الأنشطة المالية المختلفة قد تتطلب مستويات رؤية مختلفة.
يمكن للحساب العام أن يوفر شفافية مباشرة، بينما يمكن لـ Phoenix توفير خصوصية أقوى للمعاملات. تصف وثائق Dusk هذين النموذجين بوصفهما متكاملين لا كنُظُم متنافسة.
بالنسبة لـ @Dusk ، فإن الفكرة المعمارية الأعمق هي المرونة: لا يحتاج المستخدمون إلى الاختيار بين بلوكتشين شفافة بالكامل وبلوكتشين خاصة بالكامل.

$DUSK #dusk

هل يمكن أن يصبح توفير نموذجين للمعاملات—شفاف ومُحصّن—متطلباً مهماً لبنية تحتية مالية جادة على السلسلة (on chain)؟

إثبات موجز: كيف يصل “الغسق” إلى الحتمية النهائية.

ما الذي تحتاجه سلسلة الكتل فعليًا لجعل المعاملة نهائية؟

بالنسبة إلى Dusk تبدأ الإجابة بـ Succinct Attestation، وهو بروتوكول إجماع إثبات الحصة. تم تصميم الآلية حول لجان منتقاة عشوائيًا من المزوّدين (provisioners)، وتسلسل من خطوات التحقق من المقترحات والمصادقة عليها.
يقوم المزوّد بتأمين DUSK كرهان (stake)، ويمكنه بعد ذلك أن يصبح مؤهلًا للمشاركة في الإجماع. يختار sortition الحتمي لـ Dusk مُولّدي الكتل وأعضاء لجنة التصويت عبر عملية مُرجّحة بالحصة، ما يجعل الاختيار قابلاً لإعادة الإنتاج مع الحفاظ على قدر من عدم التوقع عبر “بذرة” (seed) البروتوكول.
الجزء المثير هو ما يحدث بعد اقتراح كتلة. تقوم لجنة بالتحقق منها بينما تقوم لجنة أخرى بالمصادقة على نتيجة التحقق. يؤدي الحصول على أغلبية فائقة من الأصوات الصحيحة إلى نتيجة ناجحة، مع استخدام تواقيع BLS التي تتيح تجميع الأصوات في إثباتات (attestations) موجزة ومضغوطة.
بعد ذلك يستخدم Dusk حتمية متدرجة (rolling finality) بدلًا من اعتبار كل كتلة مقبولة غير قابلة للاستبدال فورًا. تتقدم الكتل عبر حالات تشمل: accepted وattested وconfirmed وصولًا إلى finally final. ولا يمكن استبدال كتلة نهائية وفق قواعد الحتمية في البروتوكول.
تُظهر هذه البنية أن الحتمية ليست مجرد مسألة سرعة. بل هي تتعلق بتنسيق المشاركين في الشبكة لإثبات التوافق، وزيادة الثقة تدريجيًا في السلسلة.
@Dusk إذن لا يجعل الإجماع مجرد آلية أمان، بل عنصرًا معماريًا داخل البنية التحتية المالية.

$DUSK #dusk

هل تُعدّ الحتمية النهائية القابلة للتوقع والقابلة للتحقق أكثر أهمية لسلاسل الكتل المالية من مجرد تعظيم إنتاجية المعاملات؟

ماذا يحدث قبل أن تتمكن بلوكتشين من الوصول إلى الإجماع؟

يحتاج الشبكة أولاً إلى طريقة موثوقة لنقل المعلومات بين العقد.
وهنا تصبح Kadcast جزءاً مهماً من معمارية Dusk.
ووفقاً للورقة البيضاء الخاصة بـ Dusk فإن Kadcast هي طبقة الاتصال من نظير إلى نظير المسؤولة عن بث المعاملات والكتل وقرارات/أصوات الإجماع. يتم بناؤها على جدول التجزئة الموزع Kademlia باستخدام مسافة XOR لتنظيم كيفية تواصل العقد.
والجزء المثير للاهتمام هو تصميم البث. بدلاً من أن تقوم كل عقدة بإعادة توجيه الرسائل إلى جميع جيرانها، تستخدم Kadcast أقراناً مختارين على مسافات متزايدة وتنظم الانتشار عبر أشجار بث متعددة (multicast trees). الهدف هو توسيع تغطية الشبكة بشكل أكبر مع عدد أقل من عمليات الإرسال المتكررة غير الضرورية
وهذا مهم لأن كفاءة الاتصال تؤثر مباشرة على مدى سرعة انتقال المعلومات عبر شبكة لامركزية. صممت Dusk تحديداً Kadcast للبيئات التي تهم فيها موارد الشبكة واتصالات منخفضة التأخير. كما تشير الورقة البيضاء إلى أن بنيتها يمكن أن تحجب نقاط منشأ الرسائل بشكل طبيعي عبر تجنب الاتصالات المباشرة من نظير إلى نظير.
لذا فإن Kadcast ليست مجرد تفصيل شبكي. بل هي جزء من الأساس الذي يربط طبقة المعاملات في Dusk بآلية الإجماع الخاصة بها.
بالنسبة لـ @Dusk فإن التواصل الفعّال يتعلق في النهاية بتهيئة الظروف للتنسيق الموثوق عبر الشبكة.

$DUSK
#dusk

مع نمو شبكات البلوكشين، هل ستصبح بنية الاتصالات مهمة بقدر أهمية الإجماع نفسه؟

ما الذي يجعل معمارية البلوكشين مختلفة فعلاً؟
مع Dusk ليست الإجابة ميزة واحدة معزولة. بل هي كيفية تصميم عدة طبقات لتعمل معًا.
في الأساس توجد DuskDS طبقة التوافق النهائي لل شبكة وإتاحة البيانات. وفوق ذلك تدعم Dusk مسارين مختلفين للتنفيذ: DuskVM حيث يتم تنفيذ عقود Rust/WASM مباشرة على Dusk L1، وDuskEVM الذي يوفّر بيئة EVM مع استخدام DuskDS للتسوية وإتاحة البيانات.
كما أن طبقة الشبكات مهمة أيضًا. تستخدم Dusk Kadcast لنشر الكتل ومعاملات الشبكة و أصوات التوافق. ويهدف نهجها المنظم إلى تقليل تكرار الرسائل وتحسين كفاءة التواصل داخل الشبكة.
ثم تأتي طبقة المعاملات. يوفّر Moonlight معاملات عامة قائمة على الحسابات، بينما يوفّر Phoenix نموذج UTXO مُشفّى. وهذا يعني أن الخصوصية لا تُعامل كفكرة لاحقة؛ بل هي جزء من معمارية المعاملات في البروتوكول.
هذا الجمع هو ما يجعل @Dusk
مثيرة للاهتمام في التحليل. بدلًا من إجبار كل تطبيق على نموذج تنفيذ واحد، تفصل Dusk بين الشبكات والتوافق والتسوية والتنفيذ وخصوصية المعاملات إلى مكوّنات متكاملة.
$DUSK sits ضمن هذه المعمارية كالأصل الأصلي لرسوم المعاملات والـ staking.
والسؤال الأعمق هو: هل تمنح هذه المعمارية المعيارية لـ Dusk ميزة ملموسة مع تطور البنية التحتية للبلوكشين؟
#dusk

لماذا تحتاج الخدمات المالية التقليدية إلى بلوكتشين مُصمّم بشكل مختلف منذ البداية؟

التحدّي ليس مجرد وضع الأصول المالية على السلسلة. فأسواق المال تحتاج إلى الخصوصية وقابلية التدقيق والامتثال التنظيمي وقابلية التوسع والنهائية الموثوقة في الوقت نفسه. تعرض الورقة البيضاء الخاصة بـ Dusk هذا كمسألة بنية تحتية أساسية: لا يمكن دائمًا تعريض المعلومات المالية الحسّاسة للعامة، لكن المؤسسات ما زالت بحاجة إلى آليات تدعم الإشراف والامتثال.

وهنا يقدّم @Dusk نهجًا معماريًا مختلفًا.

بدلًا من اعتبار الخصوصية طبقة خارجية، تُدمج Dusk ذلك داخل الشبكة عبر نماذج معاملاتِها. يوفّر Moonlight نموذجًا شفافًا قائمًا على الحساب، بينما يستخدم Phoenix تصميمًا قائمًا على UTXO للمعاملات المُحمية. كما توضح الورقة البيضاء كذلك “الاستشهاد الموجز” (Succinct Attestation) كآلية إجماع مُصممة لتحقيق نهائية خلال ثوانٍ، مع استهداف متطلبات زمن التأخر المنخفض في أسواق المال.
النقطة المهمة هي أن Dusk لا تقدّم تبنّي البلوكتشين باعتباره مشكلة تقنية بحتة. بل تحاول معالجة المتطلبات المؤسسية التي تحدد ما إذا كانت البنية التحتية المالية يمكنها فعليًا العمل على السلسلة.
وهذا يجعل $DUSK مثيرًا للاهتمام لدراسته بعيدًا عن دوره كرمز: السؤال الحقيقي هو ما إذا كان يمكن أن تتعايش الخصوصية والامتثال ومتطلبات التنفيذ الأصلية للبلوكتشين دون إجبار المؤسسات على التنازل عن أيٍّ منها.

#dusk

هل يمكن لبنية بلوكتشين تحتية أن تلبي فعليًا كِلا المتطلبات: امتثال المؤسسات وخصوصية المستخدمين، على نطاق واسع؟