Crypto knowledge P
164 منشورات
Crypto knowledge P
15 تتابع
1.4K+ المتابعون
518 إعجاب
منشورات
🎁🎁ادعاء المغلف الأحمر بسرعة 🎁🎁
يبدو اتصال محفظة Dusk كأنه نقرة واحدة بسيطة في الغسق. لكن عندما بدأت أبحث في ما يحدث خلف الكواليس، أدركت أن هناك الكثير مما يجري.
لقد مررت أولاً بمسار اكتشاف المحفظة. لا تقوم dApp بمجرد الاستيلاء على أي محفظة Dusk موجودة على الصفحة. المحفظات تُعرِّف عن نفسها، وdApp تكتشفها، وإذا كان هناك أكثر من محفظة مثبتة، يجب اختيار مزوّد. كما يحمل كل مزوّد هويته الخاصة. إنها تفاصيل صغيرة، لكنها مهمة لأن الموقع يحتاج إلى معرفة أي محفظة يتحدث معها فعليًا.
ثم نظرت إلى جانب الأذونات. طلب الملف الشخصي، وعنوان الاستلام المحمي، والمعاملة، ونداء العقد، أو التوقيع ليست كلها شيئًا واحدًا. تمر عبر طلبات محفظة مختلفة، ويمكن للمحفظة أيضًا الإبلاغ عن تغييرات في الملف الشخصي والسلسلة والعقدة المحددة أثناء استمرار الاتصال. لذلك فإن عبارة “متصل” لا تعني فعليًا أن dApp لديها وصولًا غير محدود.
كان جزء التوقيع هو الأكثر إثارة للاهتمام بالنسبة لي. تضيف Dusk المعرف الأصلي (origin) ومعرّف السلسلة إلى سياق الرسالة الموقعة. كما أن توقيع المصادقة يتضمن أيضًا nonce وطرْقات زمنية (timestamps). لذلك فالتوقيع ليس مجرد “هذا الحساب وقّع شيئًا” — بل توجد أيضًا سياقات حول الطلب نفسه.
كما راجعت التغييرات الأخيرة على المحفظة المتعلقة بهذا الأمر. تم تقييد رسائل المزوّد بحيث لا يمكن لأي مزوّد Dusk مثبت آخر تلقي نفس طلب dApp. وتم تشديد التعامل مع origin والأذونات، وتم تقييد اتصالات dApp RPC والاتصالات بخوادم عقدة مخصّصة لتكون عبر HTTPS أو نقاط نهاية التطوير المحلي. كما تذكر ملاحظات أمان Dusk نفسها حدودًا مثل أن ذاكرة JavaScript لا يمكن محوها بشكل موثوق.
بالنسبة لي، يغيّر هذا شكل زر “Connect Wallet” الصغير. الأمر ليس مجرد إذن واحد. توجد طبقة كاملة بين الموقع والمفتاح تتولى تحديد أي محفظة تُستخدم، وما الذي يمكن لـ dApp طلبه، وما الذي يوقّعه المستخدم فعليًا.
$DUSK @Dusk #dusk
لقد مررت أولاً بمسار اكتشاف المحفظة. لا تقوم dApp بمجرد الاستيلاء على أي محفظة Dusk موجودة على الصفحة. المحفظات تُعرِّف عن نفسها، وdApp تكتشفها، وإذا كان هناك أكثر من محفظة مثبتة، يجب اختيار مزوّد. كما يحمل كل مزوّد هويته الخاصة. إنها تفاصيل صغيرة، لكنها مهمة لأن الموقع يحتاج إلى معرفة أي محفظة يتحدث معها فعليًا.
ثم نظرت إلى جانب الأذونات. طلب الملف الشخصي، وعنوان الاستلام المحمي، والمعاملة، ونداء العقد، أو التوقيع ليست كلها شيئًا واحدًا. تمر عبر طلبات محفظة مختلفة، ويمكن للمحفظة أيضًا الإبلاغ عن تغييرات في الملف الشخصي والسلسلة والعقدة المحددة أثناء استمرار الاتصال. لذلك فإن عبارة “متصل” لا تعني فعليًا أن dApp لديها وصولًا غير محدود.
كان جزء التوقيع هو الأكثر إثارة للاهتمام بالنسبة لي. تضيف Dusk المعرف الأصلي (origin) ومعرّف السلسلة إلى سياق الرسالة الموقعة. كما أن توقيع المصادقة يتضمن أيضًا nonce وطرْقات زمنية (timestamps). لذلك فالتوقيع ليس مجرد “هذا الحساب وقّع شيئًا” — بل توجد أيضًا سياقات حول الطلب نفسه.
كما راجعت التغييرات الأخيرة على المحفظة المتعلقة بهذا الأمر. تم تقييد رسائل المزوّد بحيث لا يمكن لأي مزوّد Dusk مثبت آخر تلقي نفس طلب dApp. وتم تشديد التعامل مع origin والأذونات، وتم تقييد اتصالات dApp RPC والاتصالات بخوادم عقدة مخصّصة لتكون عبر HTTPS أو نقاط نهاية التطوير المحلي. كما تذكر ملاحظات أمان Dusk نفسها حدودًا مثل أن ذاكرة JavaScript لا يمكن محوها بشكل موثوق.
بالنسبة لي، يغيّر هذا شكل زر “Connect Wallet” الصغير. الأمر ليس مجرد إذن واحد. توجد طبقة كاملة بين الموقع والمفتاح تتولى تحديد أي محفظة تُستخدم، وما الذي يمكن لـ dApp طلبه، وما الذي يوقّعه المستخدم فعليًا.
$DUSK @Dusk #dusk
تمّ التحقق
أعتقد أننا غالبًا ما نطرح السؤال الخاطئ عندما تفشل معاملة “Dusk”.
مجرد الحصول على 202 Accepted فقط يعني أن العقدة قبلت الطلب للتوجيه. ولا يعني ذلك أن المعاملة موجودة بالفعل في mempool أو ضمن كتلة. مثال وجدته مثيرًا للاهتمام هو nonce مستقبلي. إذا وصلت معاملة Moonlight بــ nonce مستقبلي بينما كان nonce سابق لا يزال مفقودًا، يمكن لـ Dusk إبقاؤها خارج الـ real mempool والانتظار حتى يُغلق فجوة الـ nonce بدلًا من رفضها فورًا. تحصل عندها على حالة مؤجلة.
هذا جزء واحد فقط من القصة. بعد اجتياز المعاملة لمرحلة القبول، تدخل الـ mempool المحلية لتلك العقدة. تحتفظ العقد الأخرى بمراكز mempool الخاصة بها وتجري أيضًا فحوصات القبول الخاصة بها. لاحقًا، يمكن اختيار المعاملة لكتلة، وتنفيذها، وفي النهاية يتم إتمامها (finalized). كما يمكنها مغادرة الـ mempool المحلية دون أن يعني ذلك تلقائيًا أنها فشلت. يمكن أن تؤدي الإتاحة (Expiry) والاستبدال (replacement) وحدود السعة والتعارضات جميعها إلى الإزالة.
وهنا أرى أن الفرق يهم للـ wallets و exchanges. توجيه التكامل الخاص بـ Dusk يقول للاحتفاظ بالمعاملة الموقعة نفسها حرفيًا، ومعاملة 202 Accepted على أنها نجاح توجيه فقط، ثم إعادة بثّ نفس البايتات الموقعة بعد مهلة انتهاء النقل (transport timeout) بدلًا من إنشاء معاملة جديدة بشكل أعمى. يجب اعتبار عملية السحب مكتملة فقط بعد التحقق من تنفيذها وأن الكتلة قد اكتملت.
كلما نظرت أكثر، قلّ شعوري بأن عبارة “transaction submitted” تبدو حالة مفيدة بذاتها. يمكن أن تكون المعاملة تنتظر nonce، أو تكون موجودة في الـ mempool لإحدى العقد، أو تُنفَّذ مع خطأ، أو تكون متواجدة في كتلة غير مكتملة بعد. هذه حالات مختلفة جدًا، حتى لو كانت جميعها قد تبدو من الخارج وكأنها “لا تزال معلّقة”.
بالنسبة لي، هذه هي الخلاصة المفيدة من تدفق معاملات Dusk: submitted هو البداية فقط. الأهم هو حالة يمكنك إثباتها فعليًا أن المعاملة وصلت إليها.
$DUSK @Dusk #dusk
مجرد الحصول على 202 Accepted فقط يعني أن العقدة قبلت الطلب للتوجيه. ولا يعني ذلك أن المعاملة موجودة بالفعل في mempool أو ضمن كتلة. مثال وجدته مثيرًا للاهتمام هو nonce مستقبلي. إذا وصلت معاملة Moonlight بــ nonce مستقبلي بينما كان nonce سابق لا يزال مفقودًا، يمكن لـ Dusk إبقاؤها خارج الـ real mempool والانتظار حتى يُغلق فجوة الـ nonce بدلًا من رفضها فورًا. تحصل عندها على حالة مؤجلة.
هذا جزء واحد فقط من القصة. بعد اجتياز المعاملة لمرحلة القبول، تدخل الـ mempool المحلية لتلك العقدة. تحتفظ العقد الأخرى بمراكز mempool الخاصة بها وتجري أيضًا فحوصات القبول الخاصة بها. لاحقًا، يمكن اختيار المعاملة لكتلة، وتنفيذها، وفي النهاية يتم إتمامها (finalized). كما يمكنها مغادرة الـ mempool المحلية دون أن يعني ذلك تلقائيًا أنها فشلت. يمكن أن تؤدي الإتاحة (Expiry) والاستبدال (replacement) وحدود السعة والتعارضات جميعها إلى الإزالة.
وهنا أرى أن الفرق يهم للـ wallets و exchanges. توجيه التكامل الخاص بـ Dusk يقول للاحتفاظ بالمعاملة الموقعة نفسها حرفيًا، ومعاملة 202 Accepted على أنها نجاح توجيه فقط، ثم إعادة بثّ نفس البايتات الموقعة بعد مهلة انتهاء النقل (transport timeout) بدلًا من إنشاء معاملة جديدة بشكل أعمى. يجب اعتبار عملية السحب مكتملة فقط بعد التحقق من تنفيذها وأن الكتلة قد اكتملت.
كلما نظرت أكثر، قلّ شعوري بأن عبارة “transaction submitted” تبدو حالة مفيدة بذاتها. يمكن أن تكون المعاملة تنتظر nonce، أو تكون موجودة في الـ mempool لإحدى العقد، أو تُنفَّذ مع خطأ، أو تكون متواجدة في كتلة غير مكتملة بعد. هذه حالات مختلفة جدًا، حتى لو كانت جميعها قد تبدو من الخارج وكأنها “لا تزال معلّقة”.
بالنسبة لي، هذه هي الخلاصة المفيدة من تدفق معاملات Dusk: submitted هو البداية فقط. الأهم هو حالة يمكنك إثباتها فعليًا أن المعاملة وصلت إليها.
$DUSK @Dusk #dusk
تمّ التحقق
لفتت انتباهي عمليات التحويل البالغ عددها 280 عملية، لكنني انتهيت إلى إيلاء اهتمام أكبر لما يحدث حولها.
لقد راجعت أحدث أعمال إنهاء (sign off) شبكة Dusk Hyperlane ذات الصلة بالعمل، وكذلك الاختبارات حتى الآن وتبيّن أنها تبدو متينة. نجح أحدث إعادة إنتاج نظيفة في اجتياز عمليات بناء العقد، واختبارات الجهاز الظاهري (VM)، واختبارات المعاملات، وفحوصات وكيل (agent) Hyperlane. بعد ذلك، عمل اختبار التحمل عالي الحجم لمدة 7 دورات، مع 20 عملية تحويل من EVM إلى Dusk و20 عملية تحويل من Dusk إلى EVM في كل دورة. وهذا يعني 280 عملية تحويل إجمالاً خلال 7,282 ثانية قبل انتهاء نافذة الاختبار التي مدتها 120 دقيقة.
لكن ما وجدته أكثر أهمية هو قائمة التحقق الخاصة بالإصدار (production) التي كانت إلى جانب تلك النتائج. ما زال تحديد حيازة (custody) المُوقّع (production signer) قيد القرار. كما توجد أيضاً قرارات مفتوحة بشأن استرداد الأموال الموضوعة في حساب إيداع معلق (pending escrow recovery)، ومدة استمرار اختبار التحمل (soak)، وكيف ينبغي أن تعمل إعدادات التكامل المستمر (CI) وقابلية إعادة الإنتاج (reproducibility). من السهل إغفال هذه الأمور عندما تكون النتيجة الرئيسية اختباراً ناجحاً، لكن هذه هي الأشياء التي أرغب في فهمها قبل أن يشارك سيولة حقيقية.
سؤال المُوقّع يصعب تجاهله بشكل خاص بعد ما حدث مع الجسر القديم من Dusk إلى EVM في يناير. حصل مهاجم على وصول إلى محفظة توقيع الجسر، وسرق DUSK منها، ثم نقل جزءاً من الأموال المسروقة عبر الجسر إلى BNB Smart Chain. كان Dusk واضحاً بأن الحادث كان اختراقاً لمحفظة الجسر، وليس استغلالاً للإجماع أو البروتوكول في Dusk. ثم تمت إعادة تصميم الجسر لاحقاً مع فصل أقوى بين عملية التوقيع، والتعامل مع الأحداث (event handling)، وإطلاق الأموال (fund release)، بالإضافة إلى ضوابط أكثر إحكاماً للرصيد والاسترداد.
لذلك لا أنظر إلى 280 عملية تحويل على أنها إشارة خضراء أو حمراء. فهي تُظهر أن النظام يتم اختباره بجدية. ما يهمني الآن هو كيف يفترض أن يتصرف النظام عندما يحدث خطأ، ومن يتحكم في الأجزاء الحساسة، وكيف تتم معالجة الاسترداد.
هذا هو ما أود أن يتم حسمه قبل اعتبار Dusk Hyperlane بنية تحتية لسيولة ذات مغزى.
$DUSK @Dusk #dusk
لقد راجعت أحدث أعمال إنهاء (sign off) شبكة Dusk Hyperlane ذات الصلة بالعمل، وكذلك الاختبارات حتى الآن وتبيّن أنها تبدو متينة. نجح أحدث إعادة إنتاج نظيفة في اجتياز عمليات بناء العقد، واختبارات الجهاز الظاهري (VM)، واختبارات المعاملات، وفحوصات وكيل (agent) Hyperlane. بعد ذلك، عمل اختبار التحمل عالي الحجم لمدة 7 دورات، مع 20 عملية تحويل من EVM إلى Dusk و20 عملية تحويل من Dusk إلى EVM في كل دورة. وهذا يعني 280 عملية تحويل إجمالاً خلال 7,282 ثانية قبل انتهاء نافذة الاختبار التي مدتها 120 دقيقة.
لكن ما وجدته أكثر أهمية هو قائمة التحقق الخاصة بالإصدار (production) التي كانت إلى جانب تلك النتائج. ما زال تحديد حيازة (custody) المُوقّع (production signer) قيد القرار. كما توجد أيضاً قرارات مفتوحة بشأن استرداد الأموال الموضوعة في حساب إيداع معلق (pending escrow recovery)، ومدة استمرار اختبار التحمل (soak)، وكيف ينبغي أن تعمل إعدادات التكامل المستمر (CI) وقابلية إعادة الإنتاج (reproducibility). من السهل إغفال هذه الأمور عندما تكون النتيجة الرئيسية اختباراً ناجحاً، لكن هذه هي الأشياء التي أرغب في فهمها قبل أن يشارك سيولة حقيقية.
سؤال المُوقّع يصعب تجاهله بشكل خاص بعد ما حدث مع الجسر القديم من Dusk إلى EVM في يناير. حصل مهاجم على وصول إلى محفظة توقيع الجسر، وسرق DUSK منها، ثم نقل جزءاً من الأموال المسروقة عبر الجسر إلى BNB Smart Chain. كان Dusk واضحاً بأن الحادث كان اختراقاً لمحفظة الجسر، وليس استغلالاً للإجماع أو البروتوكول في Dusk. ثم تمت إعادة تصميم الجسر لاحقاً مع فصل أقوى بين عملية التوقيع، والتعامل مع الأحداث (event handling)، وإطلاق الأموال (fund release)، بالإضافة إلى ضوابط أكثر إحكاماً للرصيد والاسترداد.
لذلك لا أنظر إلى 280 عملية تحويل على أنها إشارة خضراء أو حمراء. فهي تُظهر أن النظام يتم اختباره بجدية. ما يهمني الآن هو كيف يفترض أن يتصرف النظام عندما يحدث خطأ، ومن يتحكم في الأجزاء الحساسة، وكيف تتم معالجة الاسترداد.
هذا هو ما أود أن يتم حسمه قبل اعتبار Dusk Hyperlane بنية تحتية لسيولة ذات مغزى.
$DUSK @Dusk #dusk
صحيح جزئيًا
شيء صغير واحد بخصوص معاملات الغسق كان يزعجني.
كنت أقرأ عبر تدفق معاملات الغسق، واكتشفت أن معاملة واحدة حاليًا تحمل عملية واحدة. وبالنسبة لشيء أساسي، فهذا منطقي جدًا. فهو يجعل التحقق والفهم أسهل. لكن بعد ذلك فكرت في تدفق DeFi أكثر تعقيدًا، مثل تجهيز الأموال، ثم إجراء مبادلة، ثم الإيداع/الستيكينغ. بالنسبة للمستخدم، يبدو الأمر كإجراء واحد. أما في الغسق، فيتحول إلى عدة معاملات منفصلة، لكل واحدة عدّاد nonce خاص بها وتوقيع واحتمال أن يتم تضمينها.
عندها بدأت أتساءل ماذا يحدث إذا نجح جزء فقط من التسلسل. لا توجد ميزة تراجع/rollback على مستوى البروتوكول عبر تلك المعاملات، لذلك قد ينتهي بك الأمر في منتصف مسار أكبر. وبالنسبة لتجارة عادية، ربما لا تكون مشكلة كبيرة. لكن في DeFi، لعمليات التسوية أو الخزانة/treasury، أستطيع أن أرى كيف يمكن أن يصبح ذلك صداعًا حقيقيًا.
والشيء الذي وجدته مثيرًا للاهتمام هو أن الغسق لديه بالفعل تذكرة/issue مفتوحة في GitHub، رقم #4058، تناقش المعاملات المجمّعة batch transactions. إحدى الأفكار هي وجود عقد “batcher” يقوم بإدراج عدة استدعاءات داخل معاملة واحدة، لكن العقود التي تستخدم caller() قد ترى الـ batcher بدلًا من المستخدم الأصلي. والخيار الآخر هو تنفيذ batch على مستوى البروتوكول بحيث تبقى عمليات متعددة ضمن هوية المستخدم، لكن ذلك يعني إجراء تغييرات على تنسيق المعاملة، ودعم الإجماع، وتفعيل hard fork، وواجهات SDK.
لذلك لن أستبدل نموذج العملية الواحدة الحالي. أعتقد أنه من المنطقي أن يكون الوضع الافتراضي البسيط. بل أرغب في رؤية batch ذري/atomic اختياري للمهام المعقدة، حيث تُنفّذ العمليات بالترتيب، ويمكن للدفعة كاملة أن تتراجع إذا فشل أحدها، ويبقى المستخدم الأصلي ظاهرًا لكل استدعاء.
هل سيكون هذا التوازن مناسبًا للغسق، أم أن تعقيد البروتوكول الإضافي لا يستحق ذلك؟
$DUSK @Dusk #dusk
كنت أقرأ عبر تدفق معاملات الغسق، واكتشفت أن معاملة واحدة حاليًا تحمل عملية واحدة. وبالنسبة لشيء أساسي، فهذا منطقي جدًا. فهو يجعل التحقق والفهم أسهل. لكن بعد ذلك فكرت في تدفق DeFi أكثر تعقيدًا، مثل تجهيز الأموال، ثم إجراء مبادلة، ثم الإيداع/الستيكينغ. بالنسبة للمستخدم، يبدو الأمر كإجراء واحد. أما في الغسق، فيتحول إلى عدة معاملات منفصلة، لكل واحدة عدّاد nonce خاص بها وتوقيع واحتمال أن يتم تضمينها.
عندها بدأت أتساءل ماذا يحدث إذا نجح جزء فقط من التسلسل. لا توجد ميزة تراجع/rollback على مستوى البروتوكول عبر تلك المعاملات، لذلك قد ينتهي بك الأمر في منتصف مسار أكبر. وبالنسبة لتجارة عادية، ربما لا تكون مشكلة كبيرة. لكن في DeFi، لعمليات التسوية أو الخزانة/treasury، أستطيع أن أرى كيف يمكن أن يصبح ذلك صداعًا حقيقيًا.
والشيء الذي وجدته مثيرًا للاهتمام هو أن الغسق لديه بالفعل تذكرة/issue مفتوحة في GitHub، رقم #4058، تناقش المعاملات المجمّعة batch transactions. إحدى الأفكار هي وجود عقد “batcher” يقوم بإدراج عدة استدعاءات داخل معاملة واحدة، لكن العقود التي تستخدم caller() قد ترى الـ batcher بدلًا من المستخدم الأصلي. والخيار الآخر هو تنفيذ batch على مستوى البروتوكول بحيث تبقى عمليات متعددة ضمن هوية المستخدم، لكن ذلك يعني إجراء تغييرات على تنسيق المعاملة، ودعم الإجماع، وتفعيل hard fork، وواجهات SDK.
لذلك لن أستبدل نموذج العملية الواحدة الحالي. أعتقد أنه من المنطقي أن يكون الوضع الافتراضي البسيط. بل أرغب في رؤية batch ذري/atomic اختياري للمهام المعقدة، حيث تُنفّذ العمليات بالترتيب، ويمكن للدفعة كاملة أن تتراجع إذا فشل أحدها، ويبقى المستخدم الأصلي ظاهرًا لكل استدعاء.
هل سيكون هذا التوازن مناسبًا للغسق، أم أن تعقيد البروتوكول الإضافي لا يستحق ذلك؟
$DUSK @Dusk #dusk
#dusk $DUSK @Dusk
كنت أتابع مؤخراً الجانب الخاص بالشركات الصغيرة والمتوسطة (SME) في Dusk، وشيء واحد كان يعود إليّ باستمرار.
تجزئة/ترميز الـ SME تبدو بسيطة عندما تقولها في سطر واحد.
ضع الأصل على السلسلة.
ليتمكن المستثمرون من الوصول إليه.
تم.
لكن الأمر ليس بهذه البساطة حقاً.
لا يزال يتعين على شخص ما أن يقرر من يمكنه الاستثمار، وكيف تتم إدارة الملكية، وكيف تعمل عمليات التحويل، وما هي المعلومات التي يجب الإفصاح عنها، وكيف يتم تسوية الأموال فعلياً.
وهنا أعتقد أن بعض الناس أحياناً يقللون من تقدير مشكلة الأصول الحقيقية المرمّزة (RWA).
الرمز نفسه هو جزء واحد فقط من العملية. لا بد أيضاً أن تعمل المنظومة/السوق المحيطة به.
وهنا يصبح نهج Dusk مثيراً للاهتمام بالنسبة لي.
إن تركيزهم الأخير على الأسواق الخاصة وSMEs ليس في الأساس مجرد وضع أصل آخر على بلوكتشين من أجل ذلك فقط.
الأمر يتعلق أكثر بربط الأجزاء المختلفة من العملية.
لأن الجزء الصعب ليس إنشاء الرمز.
الجزء الصعب هو جعل الرمز قابلاً للاستخدام.
قد تمتلك SME ورقة/أداة مالية مُمَكَّنة بتقنية الرمز (tokenized security)، لكن إذا لم يتمكن المستثمرون من الوصول إليها بشكل صحيح، أو تعقّدت عمليات التحويل، أو لم توجد سوق حقيقية حولها، فحينها لن يتغير الكثير.
ولهذا السبب أيضاً أنا مهتم بمعرفة كيف سيتطور جانب Dusk Trade.
إذا تمكن من جعل العملية أبسط لكلا الشركات والمستثمرين، فسيصبح ذلك أكثر إثارة من مجرد سردية RWA أخرى.
ومع ذلك، ما زال الأمر في بدايته.
بالنسبة لي، الاختبار الحقيقي بسيط:
هل يستطيع Dusk أن يجعل استخدام الأسواق الخاصة أسهل فعلاً، أم أننا فقط نضع عملية قديمة على السلسلة ثم نسميها جديدة؟
هذه هي النقطة التي سأتابعها عن كثب بينما يبدأ Dusk Trade في التشكّل.
كنت أتابع مؤخراً الجانب الخاص بالشركات الصغيرة والمتوسطة (SME) في Dusk، وشيء واحد كان يعود إليّ باستمرار.
تجزئة/ترميز الـ SME تبدو بسيطة عندما تقولها في سطر واحد.
ضع الأصل على السلسلة.
ليتمكن المستثمرون من الوصول إليه.
تم.
لكن الأمر ليس بهذه البساطة حقاً.
لا يزال يتعين على شخص ما أن يقرر من يمكنه الاستثمار، وكيف تتم إدارة الملكية، وكيف تعمل عمليات التحويل، وما هي المعلومات التي يجب الإفصاح عنها، وكيف يتم تسوية الأموال فعلياً.
وهنا أعتقد أن بعض الناس أحياناً يقللون من تقدير مشكلة الأصول الحقيقية المرمّزة (RWA).
الرمز نفسه هو جزء واحد فقط من العملية. لا بد أيضاً أن تعمل المنظومة/السوق المحيطة به.
وهنا يصبح نهج Dusk مثيراً للاهتمام بالنسبة لي.
إن تركيزهم الأخير على الأسواق الخاصة وSMEs ليس في الأساس مجرد وضع أصل آخر على بلوكتشين من أجل ذلك فقط.
الأمر يتعلق أكثر بربط الأجزاء المختلفة من العملية.
لأن الجزء الصعب ليس إنشاء الرمز.
الجزء الصعب هو جعل الرمز قابلاً للاستخدام.
قد تمتلك SME ورقة/أداة مالية مُمَكَّنة بتقنية الرمز (tokenized security)، لكن إذا لم يتمكن المستثمرون من الوصول إليها بشكل صحيح، أو تعقّدت عمليات التحويل، أو لم توجد سوق حقيقية حولها، فحينها لن يتغير الكثير.
ولهذا السبب أيضاً أنا مهتم بمعرفة كيف سيتطور جانب Dusk Trade.
إذا تمكن من جعل العملية أبسط لكلا الشركات والمستثمرين، فسيصبح ذلك أكثر إثارة من مجرد سردية RWA أخرى.
ومع ذلك، ما زال الأمر في بدايته.
بالنسبة لي، الاختبار الحقيقي بسيط:
هل يستطيع Dusk أن يجعل استخدام الأسواق الخاصة أسهل فعلاً، أم أننا فقط نضع عملية قديمة على السلسلة ثم نسميها جديدة؟
هذه هي النقطة التي سأتابعها عن كثب بينما يبدأ Dusk Trade في التشكّل.
كنت أتعمّق أكثر في كيفية تعامل Dusk مع المعاملات، ولاحظت شيئًا لم أكن قد فكرت فيه من قبل.
Moonlight وPhoenix ليستا مجرد نسختين من الشيء نفسه.
Moonlight مبني على الحسابات. لديك حساب ورصيد ورقم nonce ومفاتيح، وتقوم الشبكة بالتحقق من المعاملة مقابل حالة تلك البيانات.
أما Phoenix فيتبع نهجًا مختلفًا.
يستخدم ملاحظات (notes) محفوظة داخل شجرة ميركل. عند إنفاق ملاحظة، يتم إنشاء مُبطِل (nullifier) حتى لا يمكن إنفاق نفس الملاحظة مرةً أخرى.
ما جذب انتباهي هو أن الشبكة لا تحتاج إلى الكشف عن أي ملاحظة بعينها تم إنفاقها.
وهنا تأتي أدلة ZK — يمكن التحقق من المعاملة دون كشف التفاصيل الخاصة الكامنة. كما تساعد مفاتيح الملاحظات لمرة واحدة (one-time note keys) على تقليل قابلية ربط المعاملات.
يوجد أيضًا آلية تفويض لأشياء مثل المسح وتوليد الأدلة، دون منح الطرف المفوَّض إمكانية الوصول إلى صرف الأموال.
لذلك لا أستطيع وصف الأمر ببساطة على أنه: “Moonlight شفاف وPhoenix خاص”.
إنهما نموذجَا معاملات مختلفان صُمما وفق متطلبات مختلفة، مع العمل على نفس شبكة Dusk.
وبصراحة، أعتقد أن خيار التصميم هذا مثير للاهتمام.
فأيّهما تفضّل على Dusk؟
@Dusk $DUSK #dusk
Moonlight وPhoenix ليستا مجرد نسختين من الشيء نفسه.
Moonlight مبني على الحسابات. لديك حساب ورصيد ورقم nonce ومفاتيح، وتقوم الشبكة بالتحقق من المعاملة مقابل حالة تلك البيانات.
أما Phoenix فيتبع نهجًا مختلفًا.
يستخدم ملاحظات (notes) محفوظة داخل شجرة ميركل. عند إنفاق ملاحظة، يتم إنشاء مُبطِل (nullifier) حتى لا يمكن إنفاق نفس الملاحظة مرةً أخرى.
ما جذب انتباهي هو أن الشبكة لا تحتاج إلى الكشف عن أي ملاحظة بعينها تم إنفاقها.
وهنا تأتي أدلة ZK — يمكن التحقق من المعاملة دون كشف التفاصيل الخاصة الكامنة. كما تساعد مفاتيح الملاحظات لمرة واحدة (one-time note keys) على تقليل قابلية ربط المعاملات.
يوجد أيضًا آلية تفويض لأشياء مثل المسح وتوليد الأدلة، دون منح الطرف المفوَّض إمكانية الوصول إلى صرف الأموال.
لذلك لا أستطيع وصف الأمر ببساطة على أنه: “Moonlight شفاف وPhoenix خاص”.
إنهما نموذجَا معاملات مختلفان صُمما وفق متطلبات مختلفة، مع العمل على نفس شبكة Dusk.
وبصراحة، أعتقد أن خيار التصميم هذا مثير للاهتمام.
فأيّهما تفضّل على Dusk؟
@Dusk $DUSK #dusk
🔥 Phoenix
50%
🌙 Moonlight
10%
⚡ Both
20%
🤔 Depends on the use case
20%
10 الأصوات • تمّ إغلاق التصويت
إن كون الرمز على السلسلة (On-Chain) ليس سوى البداية.
السؤال الحقيقي هو: هل يمكن أيضًا نقل القواعد الخاصة بذلك الأصل إلى السلسلة؟
خذ سندًا خاضعًا لتنظيم.
قد تكون عملية تحويله إلى رمز هي الجزء السهل. لكن سوقًا ماليًا حقيقيًا يحتاج إلى المزيد:
• يجب أن يكون المستثمرون المؤهلون فقط قادرين على امتلاكه
• قد يلزم أن تتضمن عمليات النقل قيودًا مدمجة
• يجب ألا تكون المراكز الحساسة متاحة للعامة افتراضيًا
• يجب أن يحصل الأطراف الصحيحة على المعلومات الصحيحة
• يجب أن يتم تسوية النقد وتسليم الأصل معًا
هنا تصبح “الترميز” أكثر من مجرد غلاف رقمي.
تصبح بنية تحتية للسوق.
لهذا يبرز أمامي @Dusk . تركيزه لا يقتصر على مجرد وضع الأصول على السلسلة، بل يهدف إلى تمكين مسارات عمل خاضعة للتنظيم حولها—نقل مُتحكم به، وإفصاح انتقائي، وخصوصية، وأهلية، وتسوية كأجزاء مترابطة من نظام واحد.
الفرصة الأكبر ليست فقط في الأصول المُرمّزة.
بل في الأسواق القابلة للبرمجة:
قواعد تتبع الأصل.
خصوصية يمكن أن تتعايش مع المساءلة.
تسوية تحدث كجزء من المعاملة.
تغيرات في الملكية لا تُخل بمتطلبات الامتثال.
إذا نجح هذا النموذج على نطاق واسع، فقد يبدو التمويل على السلسلة أقل شبهًا بالأسواق التقليدية مع قاعدة بيانات جديدة—والمزيد كنظام مالي مُعاد تصميمه.
ما رأيك، ما أصعب عائق أمام التمويل الواقعي للانتقال إلى السلسلة: الهوية أم الخصوصية أم التداول أم التسوية أم إدارة الأصول؟
$DUSK #dusk @Dusk
السؤال الحقيقي هو: هل يمكن أيضًا نقل القواعد الخاصة بذلك الأصل إلى السلسلة؟
خذ سندًا خاضعًا لتنظيم.
قد تكون عملية تحويله إلى رمز هي الجزء السهل. لكن سوقًا ماليًا حقيقيًا يحتاج إلى المزيد:
• يجب أن يكون المستثمرون المؤهلون فقط قادرين على امتلاكه
• قد يلزم أن تتضمن عمليات النقل قيودًا مدمجة
• يجب ألا تكون المراكز الحساسة متاحة للعامة افتراضيًا
• يجب أن يحصل الأطراف الصحيحة على المعلومات الصحيحة
• يجب أن يتم تسوية النقد وتسليم الأصل معًا
هنا تصبح “الترميز” أكثر من مجرد غلاف رقمي.
تصبح بنية تحتية للسوق.
لهذا يبرز أمامي @Dusk . تركيزه لا يقتصر على مجرد وضع الأصول على السلسلة، بل يهدف إلى تمكين مسارات عمل خاضعة للتنظيم حولها—نقل مُتحكم به، وإفصاح انتقائي، وخصوصية، وأهلية، وتسوية كأجزاء مترابطة من نظام واحد.
الفرصة الأكبر ليست فقط في الأصول المُرمّزة.
بل في الأسواق القابلة للبرمجة:
قواعد تتبع الأصل.
خصوصية يمكن أن تتعايش مع المساءلة.
تسوية تحدث كجزء من المعاملة.
تغيرات في الملكية لا تُخل بمتطلبات الامتثال.
إذا نجح هذا النموذج على نطاق واسع، فقد يبدو التمويل على السلسلة أقل شبهًا بالأسواق التقليدية مع قاعدة بيانات جديدة—والمزيد كنظام مالي مُعاد تصميمه.
ما رأيك، ما أصعب عائق أمام التمويل الواقعي للانتقال إلى السلسلة: الهوية أم الخصوصية أم التداول أم التسوية أم إدارة الأصول؟
$DUSK #dusk @Dusk
صحيح جزئيًا
يتحدث الجميع عن قابلية توسّع البلوك تشين.
تقريبًا لا أحد يتحدث عن تكلفة التذكّر.
يمكن للشبكة معالجة كميات هائلة من النشاط، لكن كل بلوك وكل حدث وكل انتقال في الحالة أيضًا يخلق بيانات تاريخية لا بد في النهاية من تخزينها وصيانتها.
ولهذا وجدت تحديث البنية التحتية الأخير من Dusk أكثر إثارة للاهتمام من أي عنوان آخر عن TPS.
قلّص Dusk تخزين أحداث عقد الأرشيف من 310.7 ميغابايت إلى 27.7 ميغابايت — أي أكثر من 90% — مع الحفاظ على النتائج التاريخية.
الجزء المثير للاهتمام ليس مجرد الرقم.
بل ما الذي يشير إليه ذلك حول بنية البلوك تشين التحتية.
إذا كانت الشبكات في نهاية المطاف ستدعم الأصول المالية والتطبيقات التي قد تحتاج سنوات من التحقق التاريخي، تصبح كفاءة التخزين جزءًا من بنية النظام نفسها.
قابلية التوسّع ليست فقط حول معالجة المزيد. إنها أيضًا حول حمل بيانات أقل دون فقدان التاريخ الذي يجعل الشبكة قابلة للتحقق.
على الأرجح لن تؤدي هذه التحسينات إلى أكثر العناوين صخبًا.
لكن أعمال البنية التحتية المملة غالبًا هي ما يجعل التبنّي على نطاق واسع ممكنًا.
لا يكتفي Dusk بالعمل على ما يحدث داخل السلسلة (on-chain).
بل يعمل أيضًا على تحسين مدى كفاءة قدرة الشبكة على تذكّر ما حدث.
@Dusk $DUSK #dusk
تقريبًا لا أحد يتحدث عن تكلفة التذكّر.
يمكن للشبكة معالجة كميات هائلة من النشاط، لكن كل بلوك وكل حدث وكل انتقال في الحالة أيضًا يخلق بيانات تاريخية لا بد في النهاية من تخزينها وصيانتها.
ولهذا وجدت تحديث البنية التحتية الأخير من Dusk أكثر إثارة للاهتمام من أي عنوان آخر عن TPS.
قلّص Dusk تخزين أحداث عقد الأرشيف من 310.7 ميغابايت إلى 27.7 ميغابايت — أي أكثر من 90% — مع الحفاظ على النتائج التاريخية.
الجزء المثير للاهتمام ليس مجرد الرقم.
بل ما الذي يشير إليه ذلك حول بنية البلوك تشين التحتية.
إذا كانت الشبكات في نهاية المطاف ستدعم الأصول المالية والتطبيقات التي قد تحتاج سنوات من التحقق التاريخي، تصبح كفاءة التخزين جزءًا من بنية النظام نفسها.
قابلية التوسّع ليست فقط حول معالجة المزيد. إنها أيضًا حول حمل بيانات أقل دون فقدان التاريخ الذي يجعل الشبكة قابلة للتحقق.
على الأرجح لن تؤدي هذه التحسينات إلى أكثر العناوين صخبًا.
لكن أعمال البنية التحتية المملة غالبًا هي ما يجعل التبنّي على نطاق واسع ممكنًا.
لا يكتفي Dusk بالعمل على ما يحدث داخل السلسلة (on-chain).
بل يعمل أيضًا على تحسين مدى كفاءة قدرة الشبكة على تذكّر ما حدث.
@Dusk $DUSK #dusk
تمّ التحقق
تحديث One Dusk الذي أعتقد أنه يستحق مزيدًا من الاهتمام هو إطلاق شبكة الاختبار DuskEVM.
في البداية، قد لا يبدو "بيئة EVM أخرى" مثيرًا للاهتمام بشكل خاص. لكن البنية المعمارية تحكي قصة مختلفة.
يُدخل DuskEVM Solidity وHardhat وأدوات Ethereum القياسية إلى Dusk، بينما يتم التسوية التنفيذية عبر DuskDS. تُعد هذه الفِصْلة مهمة لأن المطورين يمكنهم استخدام مكدس تطبيقات مألوف دون التخلي عن طبقة التسوية والأولوية للبيانات الأصلية في Dusk.
والجزء الأكثر إثارة للاهتمام هو ما يحيط بذلك.
تقوم Dusk أيضًا ببناء Dusk Trade كطبقة تطبيقية للأصول المالية المُرمّزة، مع سير عمل يتناول استقبال المستثمرين، وربط المحافظ، والتحويلات الخاضعة للرقابة، وتنسيق المدفوعات، والتسوية المتوافقة.
لذلك فإن التطور الأخير ليس مجرد إضافة توافق مع EVM.
يبدو الأمر أكثر كأن Dusk تتجه نحو منظومة متكاملة حيث تتعامل أجزاء مختلفة مع مشكلات مختلفة:
→ DuskDS: الإجماع والتسوية وتوفّر البيانات
→ DuskEVM: تنفيذ EVM مألوف
→ DuskVM: تنفيذ أصلي بـ Rust/WASM مع وصول مباشر إلى قدرات خصوصية Dusk
→ Dusk Trade: بنية تحتية على مستوى التطبيق للأسواق المُرمّزة
ومن هنا تصبح أطروحة RWA أكثر إثارة للاهتمام.
ترميز أحد الأصول سهل نسبيًا في وصفه. أما بناء البنية التحتية الفعلية للإصدار، والأهلية، والتحويلات، والخصوصية، والإفصاح، والتسوية فهو المشكلة الأصعب.
ومع توفر DuskEVM للاختبار، وبناء Dusk Trade حول سير عمل حقيقي في السوق، فالأمر الذي سأراقبه بعد ذلك ليس مجرد إعلان آخر.
بل ما الذي يبنيه المطورون والتطبيقات المالية فعليًا فوق هذا المكدس.
@Dusk $DUSK #dusk
في البداية، قد لا يبدو "بيئة EVM أخرى" مثيرًا للاهتمام بشكل خاص. لكن البنية المعمارية تحكي قصة مختلفة.
يُدخل DuskEVM Solidity وHardhat وأدوات Ethereum القياسية إلى Dusk، بينما يتم التسوية التنفيذية عبر DuskDS. تُعد هذه الفِصْلة مهمة لأن المطورين يمكنهم استخدام مكدس تطبيقات مألوف دون التخلي عن طبقة التسوية والأولوية للبيانات الأصلية في Dusk.
والجزء الأكثر إثارة للاهتمام هو ما يحيط بذلك.
تقوم Dusk أيضًا ببناء Dusk Trade كطبقة تطبيقية للأصول المالية المُرمّزة، مع سير عمل يتناول استقبال المستثمرين، وربط المحافظ، والتحويلات الخاضعة للرقابة، وتنسيق المدفوعات، والتسوية المتوافقة.
لذلك فإن التطور الأخير ليس مجرد إضافة توافق مع EVM.
يبدو الأمر أكثر كأن Dusk تتجه نحو منظومة متكاملة حيث تتعامل أجزاء مختلفة مع مشكلات مختلفة:
→ DuskDS: الإجماع والتسوية وتوفّر البيانات
→ DuskEVM: تنفيذ EVM مألوف
→ DuskVM: تنفيذ أصلي بـ Rust/WASM مع وصول مباشر إلى قدرات خصوصية Dusk
→ Dusk Trade: بنية تحتية على مستوى التطبيق للأسواق المُرمّزة
ومن هنا تصبح أطروحة RWA أكثر إثارة للاهتمام.
ترميز أحد الأصول سهل نسبيًا في وصفه. أما بناء البنية التحتية الفعلية للإصدار، والأهلية، والتحويلات، والخصوصية، والإفصاح، والتسوية فهو المشكلة الأصعب.
ومع توفر DuskEVM للاختبار، وبناء Dusk Trade حول سير عمل حقيقي في السوق، فالأمر الذي سأراقبه بعد ذلك ليس مجرد إعلان آخر.
بل ما الذي يبنيه المطورون والتطبيقات المالية فعليًا فوق هذا المكدس.
@Dusk $DUSK #dusk
كلما نظرت إلى التجزئة (tokenization)، زاد اعتقادي أننا نطرح السؤال الخاطئ.
يسأل الجميع: “هل يمكن وضع هذا الأصل على السلسلة (onchain)؟”
لكن تخيّل أن الأصل موجود بالفعل.
الآن يريد مستثمر شراءه. ويريد آخر بيعه. يحتاج المُصدر إلى فرض من يمكنه امتلاك هذا الأصل. وقد يحتاج المنظّم لاحقًا إلى أدلة. وفي مكان ما بين ذلك، يجب ألا تتحول المعلومات الحساسة إلى بيانات عامة.
هذه هي الجهة الشيقة بالنسبة لي في @Dusk . إن البنية التحتية للسوق تُصمَّم لتكون حول سير العمل بالكامل — الأهلية، والتحويلات الخاضعة للضبط، والخصوصية، والإفصاح، والتسوية — بدل التعامل مع الرمز بوصفه المنتج النهائي.
ربما لن يكون الاختراق الحقيقي في أصول العالم الحقيقي (RWA) هو إنشاء المزيد من الرموز.
ربما سيكون في جعل تلك الرموز تتصرف فعلًا مثل الأصول المالية.
أي جزء من سير العمل برأيك هو الأصعب في الحل؟
$DUSK #dusk @Dusk
يسأل الجميع: “هل يمكن وضع هذا الأصل على السلسلة (onchain)؟”
لكن تخيّل أن الأصل موجود بالفعل.
الآن يريد مستثمر شراءه. ويريد آخر بيعه. يحتاج المُصدر إلى فرض من يمكنه امتلاك هذا الأصل. وقد يحتاج المنظّم لاحقًا إلى أدلة. وفي مكان ما بين ذلك، يجب ألا تتحول المعلومات الحساسة إلى بيانات عامة.
هذه هي الجهة الشيقة بالنسبة لي في @Dusk . إن البنية التحتية للسوق تُصمَّم لتكون حول سير العمل بالكامل — الأهلية، والتحويلات الخاضعة للضبط، والخصوصية، والإفصاح، والتسوية — بدل التعامل مع الرمز بوصفه المنتج النهائي.
ربما لن يكون الاختراق الحقيقي في أصول العالم الحقيقي (RWA) هو إنشاء المزيد من الرموز.
ربما سيكون في جعل تلك الرموز تتصرف فعلًا مثل الأصول المالية.
أي جزء من سير العمل برأيك هو الأصعب في الحل؟
$DUSK #dusk @Dusk
قبل أيام كنت أفكر فيما يعنيه فعلًا «ترميز أحد الأصول». في البداية يبدو الأمر بسيطًا — خذ سهمًا أو سندًا أو أصلًا ماليًا وضعه على السلسلة. لكن إنشاء الرمز ربما يكون الجزء الأسهل.
الأسئلة الأصعب تبدأ بعد ذلك. من يمكنه فعلًا الاحتفاظ به؟ ماذا يحدث عندما يحاول شخص ما نقله إلى المحفظة غير الصحيحة؟ ما المعلومات التي يجب أن تكون مرئية للامتثال، وما الذي ينبغي أن يبقى خاصًا؟
هنا تحديدًا يصبح <$DUSK > مثيرًا للاهتمام بالنسبة لي. الأصول المالية الحقيقية تحتاج إلى أكثر من مجرد تحويلات سريعة — فهي تحتاج إلى قواعد وخصوصية وتحقق وتسوية تعمل معًا دون تحويل كل شيء إلى جدول بيانات عام.
ربما ليست التحدية الحقيقية في RWA هي وضع الأصول على السلسلة. ربما هي بناء نظام يمكن للأسواق المالية أن تعمل داخله بالفعل دون التنازل عن الخصوصية والتحكم اللذين تعتمد عليهما بالفعل. ما برأيك أكبر عنصر مفقود؟ 👀
@Dusk <$DUSK > #Dusk
الأسئلة الأصعب تبدأ بعد ذلك. من يمكنه فعلًا الاحتفاظ به؟ ماذا يحدث عندما يحاول شخص ما نقله إلى المحفظة غير الصحيحة؟ ما المعلومات التي يجب أن تكون مرئية للامتثال، وما الذي ينبغي أن يبقى خاصًا؟
هنا تحديدًا يصبح <$DUSK > مثيرًا للاهتمام بالنسبة لي. الأصول المالية الحقيقية تحتاج إلى أكثر من مجرد تحويلات سريعة — فهي تحتاج إلى قواعد وخصوصية وتحقق وتسوية تعمل معًا دون تحويل كل شيء إلى جدول بيانات عام.
ربما ليست التحدية الحقيقية في RWA هي وضع الأصول على السلسلة. ربما هي بناء نظام يمكن للأسواق المالية أن تعمل داخله بالفعل دون التنازل عن الخصوصية والتحكم اللذين تعتمد عليهما بالفعل. ما برأيك أكبر عنصر مفقود؟ 👀
@Dusk <$DUSK > #Dusk
#dusk $DUSK
قصة أمان البلوكشين ليست “لم نعثر على أي خطأ”.
بل ما يحدث بعد أن تكشف عملية تدقيق جادة عن مشكلة.
ولهذا غصت في متاهة AEGIS حول @Dusk .
جرى شحن إصلاحات AEGIS الخاصة بـ Dusk لعام 2026 متضمنة 39 إصلاحًا أمنيًا، منها 7 حالات بالغة الخطورة.
والجزء المثير للاهتمام؟ لم تكن مجرد مشكلات سطحية.
لقد توغل التدقيق بعمق داخل الطبقات:
→ تنفيذ عزل VM (sandbox)
→ إلغاء تسلسل (deserialization) على جانب المضيف
→ منطق رسوم Phoenix وعمليات الاسترداد (refund)
→ أمن توقيعات BLS
→ مكونات الإجماع والشبكات والمكونات التشفيرية
يمكن أن تؤثر مشكلة رسوم Phoenix الواحدة على سلامة العرض (supply integrity) وتوافر السلسلة وأمان الاسترداد. أمّا مشكلة BLS فقد تضمنت البنية التشفيرية المستخدمة للتحقق من التوقيع.
لم يكتفِ AEGIS بإصلاح سطر واحد ثم المضي قدمًا. تقول Dusk إنها أعادت صياغة نموذج الملكية المتأثر، وأحكمت حدود الثقة، وأضافت فحوصات تناسق الرسوم على عدة طبقات، وقوّت مسار BLS، وأدرجت اختبارات انحدار (regression) مصممة لتشبه الاستغلال.
وبحسب Dusk، لم يجدوا أي دليل على أن حالات الخطورة الحرجة قد تم استغلالها قبل AEGIS.
بالنسبة لي، هذه هي المغزى الحقيقي.
في التمويل المنظم، الخصوصية مهمة.
لكن الخصوصية دون أمان عديمة الفائدة.
يجب أن يظل البنية التحتية قادرة على الصمود أمام التفكير العدائي قبل أن تتمكن المؤسسات من الوثوق بها.
وهذا هو الجانب من @Dusk الذي أجد أنه يستحق المتابعة:
ليس فقط ما يَعِد به البروتوكول،
بل مدى جدّيته في الاستجابة عندما يحاول شخص ما كسره.
$DUSK #dusk @Dusk
قصة أمان البلوكشين ليست “لم نعثر على أي خطأ”.
بل ما يحدث بعد أن تكشف عملية تدقيق جادة عن مشكلة.
ولهذا غصت في متاهة AEGIS حول @Dusk .
جرى شحن إصلاحات AEGIS الخاصة بـ Dusk لعام 2026 متضمنة 39 إصلاحًا أمنيًا، منها 7 حالات بالغة الخطورة.
والجزء المثير للاهتمام؟ لم تكن مجرد مشكلات سطحية.
لقد توغل التدقيق بعمق داخل الطبقات:
→ تنفيذ عزل VM (sandbox)
→ إلغاء تسلسل (deserialization) على جانب المضيف
→ منطق رسوم Phoenix وعمليات الاسترداد (refund)
→ أمن توقيعات BLS
→ مكونات الإجماع والشبكات والمكونات التشفيرية
يمكن أن تؤثر مشكلة رسوم Phoenix الواحدة على سلامة العرض (supply integrity) وتوافر السلسلة وأمان الاسترداد. أمّا مشكلة BLS فقد تضمنت البنية التشفيرية المستخدمة للتحقق من التوقيع.
لم يكتفِ AEGIS بإصلاح سطر واحد ثم المضي قدمًا. تقول Dusk إنها أعادت صياغة نموذج الملكية المتأثر، وأحكمت حدود الثقة، وأضافت فحوصات تناسق الرسوم على عدة طبقات، وقوّت مسار BLS، وأدرجت اختبارات انحدار (regression) مصممة لتشبه الاستغلال.
وبحسب Dusk، لم يجدوا أي دليل على أن حالات الخطورة الحرجة قد تم استغلالها قبل AEGIS.
بالنسبة لي، هذه هي المغزى الحقيقي.
في التمويل المنظم، الخصوصية مهمة.
لكن الخصوصية دون أمان عديمة الفائدة.
يجب أن يظل البنية التحتية قادرة على الصمود أمام التفكير العدائي قبل أن تتمكن المؤسسات من الوثوق بها.
وهذا هو الجانب من @Dusk الذي أجد أنه يستحق المتابعة:
ليس فقط ما يَعِد به البروتوكول،
بل مدى جدّيته في الاستجابة عندما يحاول شخص ما كسره.
$DUSK #dusk @Dusk
تمّ التحقق
#dusk $DUSK
تم تصميم معظم البلوكتشينات حول فكرة واحدة:
الشفافية.
لكن الأسواق المالية الواقعية تحتاج إلى شيء أكثر تعقيدًا.
لا يمكنك أن تتوقع من المؤسسات نشر كل الرصيد والمراكز وتفاصيل المعاملات على دفتر حسابات عام بحيث يراها الجميع.
هنا يصبح @Dusk مثيرًا للاهتمام.
تقوم Dusk ببناء بنية تحتية لتمويل أونشيني منظم حيث يمكن أن تعمل الخصوصية والامتثال والتسوية الحتمية معًا.
→ Moonlight للمعاملات العامة الشفافة
→ Phoenix لتحويلات محمية سرّية
→ الإفصاح الانتقائي عندما يحتاج طرف مُفوّض إلى معلومات محددة
→ DuskVM لعقود ذكية أصلية بـ Rust/WASM + ZK
→ DuskEVM لمسار تطوير متوافق مع EVM
والفكرة الأوسع تتجاوز مجرد "إضفاء طابع رقمي على أصل".
بالنسبة للأوراق المالية المنظمة، تحتاج إلى أن تعمل أهلية المستثمرين والتحويلات المُتحكَّم بها والخصوصية والإفصاح والتقارير والتسوية معًا.
وهذا الجزء هو أكثر ما يثير اهتمامي في Dusk.
الترميز سهل وصفه.
لكن بناء البنية التحتية المالية حوله هو الجزء الصعب.
تراهن Dusk على أن مستقبل التمويل الأونشيني يحتاج كليهما:
الخصوصية عندما تكون مهمة.
الشفافية عندما تكون مفيدة.
الامتثال عندما يكون مطلوبًا.
التسوية التي يمكن الوثوق بها.
هذه أطروحة تستحق المتابعة. 👀
@Dusk $DUSK #dusk
تم تصميم معظم البلوكتشينات حول فكرة واحدة:
الشفافية.
لكن الأسواق المالية الواقعية تحتاج إلى شيء أكثر تعقيدًا.
لا يمكنك أن تتوقع من المؤسسات نشر كل الرصيد والمراكز وتفاصيل المعاملات على دفتر حسابات عام بحيث يراها الجميع.
هنا يصبح @Dusk مثيرًا للاهتمام.
تقوم Dusk ببناء بنية تحتية لتمويل أونشيني منظم حيث يمكن أن تعمل الخصوصية والامتثال والتسوية الحتمية معًا.
→ Moonlight للمعاملات العامة الشفافة
→ Phoenix لتحويلات محمية سرّية
→ الإفصاح الانتقائي عندما يحتاج طرف مُفوّض إلى معلومات محددة
→ DuskVM لعقود ذكية أصلية بـ Rust/WASM + ZK
→ DuskEVM لمسار تطوير متوافق مع EVM
والفكرة الأوسع تتجاوز مجرد "إضفاء طابع رقمي على أصل".
بالنسبة للأوراق المالية المنظمة، تحتاج إلى أن تعمل أهلية المستثمرين والتحويلات المُتحكَّم بها والخصوصية والإفصاح والتقارير والتسوية معًا.
وهذا الجزء هو أكثر ما يثير اهتمامي في Dusk.
الترميز سهل وصفه.
لكن بناء البنية التحتية المالية حوله هو الجزء الصعب.
تراهن Dusk على أن مستقبل التمويل الأونشيني يحتاج كليهما:
الخصوصية عندما تكون مهمة.
الشفافية عندما تكون مفيدة.
الامتثال عندما يكون مطلوبًا.
التسوية التي يمكن الوثوق بها.
هذه أطروحة تستحق المتابعة. 👀
@Dusk $DUSK #dusk
⚡ استطلاع تجار العقود الآجلة ⚡
RSI فوق 78 = منطقة الشراء المفرط 📊
هؤلاء الرابحون الكبار يحققون مكاسب... ما هي خطوتك في العقود الآجلة؟ 👇
مخاطر عالية، مكافأة عالية — لا تتعرض للتصفية!
💬 علق على دخولك ورافعتك#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
RSI فوق 78 = منطقة الشراء المفرط 📊
هؤلاء الرابحون الكبار يحققون مكاسب... ما هي خطوتك في العقود الآجلة؟ 👇
مخاطر عالية، مكافأة عالية — لا تتعرض للتصفية!
💬 علق على دخولك ورافعتك#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
Short KERNEL
57%
Short SKL
13%
Short MOVR
27%
Short ZBT
3%
104 الأصوات • تمّ إغلاق التصويت
أي نوع من العملات المشفرة تراهن عليه في الارتفاع القادم؟ 👇
💬 علق باختيارك + لماذا
#BTC #solana #MEME #CryptoPoll #Dogecoin $NOM $ON $KAT
💬 علق باختيارك + لماذا
#BTC #solana #MEME #CryptoPoll #Dogecoin $NOM $ON $KAT
Store of Value — Bitcoin (BTC)
22%
Oracle Power— Chainlink (LINK)
14%
High-Speed Chains— Solana(SOL)
33%
Memecoins — Dogecoin (DOGE)
31%
36 الأصوات • تمّ إغلاق التصويت
استطلاع عن الجواهر المخفية الرائجة (باينانس) 💎
الجميع يشاهد BTC و ETH…
لكن الأرباح الحقيقية تأتي من الجواهر المخفية 👀
أي عملة بديلة رائجة لديها أكبر إمكانية بنسبة 10x؟$FET $RNDR $TIA
📊 صوت الآن وعلق على جواهرك المخفية
أفضل المعلومات دائمًا في التعليقات 👇
#crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
الجميع يشاهد BTC و ETH…
لكن الأرباح الحقيقية تأتي من الجواهر المخفية 👀
أي عملة بديلة رائجة لديها أكبر إمكانية بنسبة 10x؟$FET $RNDR $TIA
📊 صوت الآن وعلق على جواهرك المخفية
أفضل المعلومات دائمًا في التعليقات 👇
#crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
FET (AI narrative)
63%
RNDR (GPU / AI infrastructure)
10%
TIA (Modular blockchain)
24%
SEI (High-speed DeFi chain)
3%
71 الأصوات • تمّ إغلاق التصويت
أي عملة ميم تقوم بتجميعها الآن؟
💬 علق على عملة الميم التي لديك ثقة بها
دعنا نرى أي مجتمع هو الأقوى 👀
#MemecoinArmy #CryptoPoll #BinanceSquare #PEPE #memecoin🚀🚀🚀
$PEPE $DOGE $FLOKI
💬 علق على عملة الميم التي لديك ثقة بها
دعنا نرى أي مجتمع هو الأقوى 👀
#MemecoinArmy #CryptoPoll #BinanceSquare #PEPE #memecoin🚀🚀🚀
$PEPE $DOGE $FLOKI
DOGE
43%
SHIB
7%
PEPE
39%
OTHER (COMMENT IT)
11%
87 الأصوات • تمّ إغلاق التصويت
🚨 كن صادقًا... معظم الناس سيخطئون في هذا.
أي أصل يقود الدورة الصاعدة القادمة؟ 📈
#CryptoPoll #Binance #BTC #Web3 #Ethereum
$KITE $DENT $SENT
أي أصل يقود الدورة الصاعدة القادمة؟ 📈
#CryptoPoll #Binance #BTC #Web3 #Ethereum
$KITE $DENT $SENT
₿ Bitcoin – The king
23%
Ξ Ethereum – Smart contracts
19%
🟡BNB – Exchange+ real utility
13%
🚀 Altcoins
45%
31 الأصوات • تمّ إغلاق التصويت
سجّل الدخول لاستكشاف المزيد من المُحتوى