duskds

كنت أستمر في ارتكاب شيء واحد خاطئ أثناء التفكير في Moonlight وPhoenix: كنت أتعامل مع شكل الحالة كما لو أنه يحدد أيضًا النهائية.
بدأ هذا الافتراض يزعجني.
يصل Moonlight إلى #DuskVM حاملًا نموذج حسابي عام: Balances وSender وReceiver وAmount وNonce Progression.
أما Phoenix فمبني حول مسار مختلف تمامًا: Encrypted Notes وShielded Outputs وNullifiers وPrivate State.
كان أول انطباع لدي أنه ينبغي أن تحتاج هاتين المنظومتين المختلفتين إلى طريقتين مختلفتين للوصل إلى النهائية.
لكن ربما كنت أضيف تعقيدًا ليس موجودًا فعلًا.
يمكن أن يظل Moonlight على هيئة حساب. ويمكن أن يظل Phoenix على هيئة ملاحظات. لا يحتاج #DuskVM إلى تسوية أيٍّ منهما في صيغة حالة موحّدة فقط لتحديد متى ينتهي التنفيذ.
هذا جعلني أيضًا أعيد التفكير في #DuskDS .
كنت أظن أنه يحتاج إلى إنشاء حالة مشتركة واحدة $DUSK تحت النموذجين كليهما. أصبحت أقل اقتناعًا بذلك الآن.
يمكن أن تبقى منطقية التنفيذ متخصصة بينما يمنح Dusk L1 الناتج حدًا واحدًا نهائيًا محسومًا بشكل حتمي.
وبصراحة، هذا الفصل أكثر إثارة لاهتمامي من نماذج الحالات الفردية.
طرق مختلفة لتمثيل الحالة لا تتطلب بالضرورة إجابات مختلفة عن سؤال متى تكون تلك الحالة مكتملة نهائيًا.
الأمر الذي ما زلت أتساءل عنه هو مدى نظافة هذا الفصل عندما يصبح Moonlight وPhoenix أكثر تعقيدًا.

#dusk $DUSK @Dusk

@Dusk يبني شيئًا في مجال التمويل اللامركزي (DeFi)، وسيتطلب التمويل المُرمّز بشكل متزايد: الخصوصية دون فقدان الامتثال. تتمتع سلاسل الكتل العامة بقوة لأنها تجعل المعاملات شفافة وقابلة للتحقق، لكن الأسواق المالية المُنظَّمة لا يمكنها كشف كل رصيد أو مركز أو تفاصيل المستثمر أو المعاملة علنًا. تتعامل @Dusk مع هذا التحدي عبر الجمع بين تقنيات المعرفة الصفرية، والتحويلات السرّية، والإفصاح الانتقائي، وضوابط الوصول، والتسوية الحتمية. �
Dusk +1
ما يجعل هذا النهج مثيرًا للاهتمام هو فكرة أن الخصوصية لا يجب أن تعني إخفاء كل شيء. يمكن للمشاركين المصرّح لهم تلقي المعلومات التي يحتاجونها، بينما تظل البيانات الحساسة محمية من التعرض العام غير الضروري. قد يكون هذا مهمًا بشكل خاص للأوراق المالية المُرمّزة، والأصول الواقعية، وDeFi المؤسسي، وسير العمل المالي الآخر حيث تهم الأهلية ومتطلبات الإبلاغ وقيود التحويل وقواعد التسوية. �
DOCS +1
تستخدم Dusk أيضًا بنية معيارية، حيث يركز #DuskDS على التسوية وتوفر البيانات، و#DuskVM للتنفيذ الأصلي عبر Rust/WASM، و#DuskEVM للتطبيقات المتوافقة مع EVM. يمنح ذلك المطورين مسارات مختلفة، اعتمادًا على ما إذا كان التطبيق يعطي أولوية للخصوصية الأصلية أو لأدوات EVM المألوفة أو لبنية تحتية للتسوية المنظمة. �
DOCS
بالنسبة لي، الجزء المثير للاهتمام في Dusk ليس مجرد “الخصوصية”. بل هو الجمع بين الخصوصية والامتثال والتسوية المتوقعة ضمن بنية تحتية مالية واحدة. إذا تحركت المزيد من الأصول الواقعية والأسواق المؤسسية إلى السلسلة، فقد تصبح هذه القدرات أكثر أهمية. #dusk $DUSK

مررت من هنا لأتحدث معكم عن DuskDS، وهي إحدى الطبقات ربما الأكثر إرباكًا في بنية @Dusk 🌒 . لكن سأحاول شرحها لكم بأبسط طريقة ممكنة دون تعقيد تقني.

في المنشور السابق رأينا أن DuskEVM هي الطبقة التي يتم فيها تطوير وتشغيل التطبيقات أو العقود الذكية المتوافقة مع EVM، بينما DuskDS هي طبقة أخرى من البنية التحتية تسمح بإدارة البيانات والعمليات التي تُجرى على DuskEVM.

باختصار، تساعد DuskDS على أن تُسجَّل العمليات المنفَّذة على DuskEVM وأن ترتبط بالبنية التحتية الرئيسية لـ Dusk (Dusk L1)، مما يسهل تسويتها وتوفير البيانات.

علينا أن نضع في الاعتبار أن DuskEVM وDuskDS ليسا توكنين مختلفين ولا بلوك تشينين تتنافسان معًا. بل هما طبقات مختلفة تؤدي وظائف مختلفة داخل بنية $DUSK .

في المنشور التالي سنتحدث عن Dusk L1 وكيف يرتبط بالطبقات التي شاهدناها سابقًا.

#dusk #DuskEVM #DuskDS

أضفت اليوم موقعًا صغيرًا برقم $DUSK ، لكنني أراقب DuskEVM بشكل مختلف الآن.

الشيء الذي لفت انتباهي لم يكن مجرد التوافق مع EVM—بل طريقة قيام Hedger بجعل المعاملات الخاصة قابلة للمراجعة باستخدام التشفير المتماثل والتشفيرات البراهينية ZK. كنت أرى الخصوصية كميزة للمستخدم؛ أما الآن فأراها آلية اعتماد للتطبيقات المُنظَّمة.

@Dusk كما تدعم التنفيذ بينما يتولى DuskDS التسوية وتوافر البيانات. هذا الفصل يبدو مهمًا.

ما زلت غير متأكدًا من مدى سرعة تبنّي المستخدمين الحقيقيين له، لكن بنية النظام غيّرت وجهة نظري.

$ATM $BANK #DUSK #DUSKEVM #DuskDS #Web3

ما الذي برأيك يهم أكثر بالنسبة لـ DUSK؟

الجسر ما زال متوقفًا، وهذا ما أعود إليه باستمرار خلال فترة من الوقت.

@Dusk أوقف خدمات الجسر في 16 يناير بعد أن رصدت المراقبة نشاطًا غير متسق مع العمليات المعتادة — وهو ما يشير إلى محفظة تشغيلية مُدارة بواسطة فريق، وليس البروتوكول. لم تتوقف أبدًا حواجز DuskDS. لكن الجسر لا يزال متوقفًا بينما ينتهون من أعمال التهيئة/التقوية الصعبة، والحل للتخفيف الذي تم إصداره بالفعل هو قائمة حظر عناوين للمستلمين موجودة في Web Wallet. علِّم عنوانًا سيئًا، أطلق تحذيرًا، أوقف الإرسال.

هذا كل شيء. هذه هي شبكة الأمان.

وهنا ما لا أستطيع التوقف عن التفكير فيه: إذا كنت تستخدم Rusk CLI أو أدواتك الخاصة، فلن يَصدر ذلك التحذير أبدًا. أنت تتمتع بسيادة كاملة — ومكشوف بالكامل. التشفير بالـ ZK الموجود أسفل ذلك عملٌ جاد جدًا. لم يلمس أيٌّ من ذلك سطح المخاطر الحقيقي لهذا الأسبوع.

لا أعتقد أن إنشاء قائمة الحظر كان قرارًا خاطئًا. عمليًا هو صحيح — غطِّ أكبر عدد من المستخدمين بأسرع طريقة، ثم أصلح البنية بعد ذلك.

لكن $DUSK تُعرِّف نفسها صراحةً بأنها تتجه للأسواق المؤسسية المُنظَّمة. إذا كانت أظهر ضوابط السلامة موجودة في Web Wallet وليس داخل البروتوكول نفسه، فهناك سؤال حقيقي عمّا يحدث عندما يقوم فريق امتثال بإجراء اختبارات ضغط فعليّة لهذه المنظومة.

هذه هي الفجوة التي أراقبها. ليس التشفير — بل الحوكمة/الإدارة المتعلقة بمكان وجود الحماية فعليًا.

إذا كانت المؤسسات تحتاج إلى ضمانات على مستوى البروتوكول، وليس تحذيرات الواجهة الأمامية، فهل خارطة طريق Dusk الحالية تمضي بسرعة كافية نحو ذلك؟

#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS