Lữ Khách Web3

هناك نقطة واحدة جعلتني أتوقف عند قراءة موضوع Dusk Network وهي: إذا كان الـ blockchain مُبنيًا أساسًا حول الشفافية، فلماذا يجب أن تكون الـ privacy في موقع مهم إلى هذا الحد داخل شبكة تتجه نحو التمويل المؤسسي؟
في البداية ظننت أن الأمر قد يكون مجرد طريقة لتحديد هوية المنتج، لكن عندما قرأت وثائق Dusk بدقة أكبر، بدأت الصورة تتضح أكثر. يصف Dusk التطبيقات المالية التي تحتاج إلى حماية balance وposition وcounterparty وbusiness logic بدلاً من وضع كامل الحالة على الـ public ledger.
واصلت التحقق من كيفية تعاملهم مع هذه المشكلة. لم يكتفِ Dusk بمجرد القول “إخفاء البيانات”. بل إن العمارة الحالية تجمع بين confidential transfers وzero-knowledge proofs وselective disclosure. يمكن الاحتفاظ ببعض المعلومات سرية على السلسلة، بينما يمكن إثبات أو كشف المعلومات الضرورية بطريقة خاضعة للرقابة.
والذي لم أتوقعه هو أن الخصوصية هنا ليست في مواجهة الامتثال بشكل مطلق. فمثلاً Citadel يستخدم selective disclosure لإثبات خصائص مثل محل الإقامة أو فئة العمر أو الاعتماد، دون الحاجة إلى نشر كل البيانات بالضرورة.
لكن ما زال هذا لا يكفي للقول إن Dusk قد حل مشكلة البيانات الحساسة في التمويل المؤسسي بالكامل. لا تزال الخصوصية تعتمد على طريقة تطبيق الحل، وأي metadata قد يظل مكشوفًا.
ومع ذلك، بعد قراءة أعمق، بدأت أنظر إلى السؤال بشكل مختلف: في التمويل عبر السلسلة، هل ليست المشكلة “الخصوصية أم الشفافية”، بل من الذي يستطيع رؤية أي بيانات، وفي أي سياق؟
#dusk $DUSK @Dusk $BTC

هناك شيء ما يجعلني أتوقف عندما أقرأ مستندات Dusk. فهم يضعون باستمرار الخصوصية والامتثال والتسوية في نفس الطبقة كأن هذه الثلاثة لا يمكن فصلها.

يقوم Dusk ببناء L1 للتمويل الخاضع للتنظيم. يقوم DuskDS ببناء طبقة التسوية وتوفّر البيانات مع حتمية نهائية عبر Succinct Attestation. وفوق ذلك يوجد نموذج معاملات مزدوج: Phoenix للمعاملات المُحصّنة، وMoonlight للمعاملات الشفافة. Citadel يدعم الإفصاح الانتقائي. يعمل DuskEVM وDuskVM على التنفيذ لكن كل شيء يُسَوَّى في النهاية إلى القاعدة نفسها.
أريد أن أرى ما إذا كان دمج هذه الأمور الثلاثة ينبع فعلًا من متطلبات تقنية أم أنه مجرد طريقة لتموضع RWA. قرأت المكوّنات الأساسية ونماذج المعاملات ثم قارنت ذلك بالطريقة التي يصفون بها سير العمل لإصدار وتسوية الأوراق المالية.

اتضح أن هناك معمارية وحداتية لكن ما زال يتم فرض منطق الخصوصية والامتثال ليكون ملاصقًا لطبقة التسوية. يستخدم Phoenix ZK لإخفاء المبلغ والمشاركين مع السماح بالاحتفاظ بمسار تدقيق. الامتثال ليس “إضافة” على مستوى التطبيق، بل تم تصميمه ليعمل بالتوازي مع النهائية.
مهلًا، ربما هذا مجرد خيار تنفيذ لسير عمل المؤسسات وليس قانونًا إلزاميًا. تفصل سلاسل أخرى كثيرة الخصوصية إلى L2 أو نظام جانبي، بينما تبقى التسوية عامة. اختار Dusk الجمع لأنهم يستهدفون الأصول الخاضعة للتنظيم، حيث تكون البيانات حساسة ويجب أن تأتي النهائية جنبًا إلى جنب لتفادي نقل المسؤوليات بين أنظمة متعددة.

وعند النظر إلى الصورة الأوسع، نرى في الصناعة نمطًا مشابهًا لدى بعض بروتوكولات RWA الأخرى: التسويق يسلّط الضوء على “الخصوصية + الامتثال المدمج أصليًا” بينما يعتمد التنفيذ فعليًا على ترخيص خارجي وأدوات مألوفة.
هل التسوية تحتاج حقًا إلى خصوصية مدمجة في الطبقة الأساسية أم يكفي أن تكون الواجهة جيدة بما يكفي لتقرر الطبقات العليا ذلك بنفسها؟
#dusk $DUSK @Dusk $BTC

هناك شيء ما يجعلني أتوقف عندما أقرأ وثائق Dusk. معظم خصوصية L1 تتحدث عن المعاملات المُشفّرة (shielded transactions)، لكن هنا يركزون على الكشف الانتقائي وضوابط الوصول مباشرةً من البروتوكول.

Dusk هي Layer1 عامة وبدون إذن (permissionless)، تركز على الإصدار الأصلي للأصول الرقمية (native issuance) والـ assets المنظمة (regulated assets). لديهم شراكة مع NPEX (تراخيص MTF وBroker وECSP)، ونموذج مزدوج Phoenix/Moonlight، وCitadel للهوية، كما يدفعون DuskEVM. تم تشغيل الـ Mainnet، وتتم تحديث الوثائق وGitHub Rusk باستمرار. أريد أن أرى ما إذا كانت بنية ما خلف الكواليس مختلفة بالفعل عن المشاريع التي تكتفي بإضافة الامتثال على مستوى التطبيق فقط. قرأت النظرة العامة (overview) والمكوّنات الأساسية ثم قارنتهما بالأخبار المتعلقة بـ NPEX وDLT-TSS. اتضح أن الامتثال مُدمج في البروتوكول: الأهلية (eligibility)، تقييد التحويل، التحويل القسري، وسجل المساهمين (shareholder registry) يمكن فكّه/تشفيره بشكل انتقائي.

الخصوصية ليست إخفاء مجهول مطلقًا، بل هي “private by default, auditable when required” (خاصة افتراضيًا، ويمكن التدقيق عند الحاجة). هذا نهج مختلف عن معظم الـ DeFi الحالي.
ومع ذلك، ربما أكون أضخم الصورة. تراخيص NPEX تخص الشركاء، وليست شيئًا يمتلكه البروتوكول بالكامل. ما يزال DLT-TSS قيد التطوير، وقد تكون هذه مجرد طريقة ينفذونها للسوق الأوروبية. كثير من البروتوكولات أيضًا تنتقل من DeFi البحت إلى بنية تحتية خاضعة للتنظيم. عادةً ما يسبق التسويق المنتج الفعلي، بينما تتأخر الاستجابة/التبنّي المؤسسي مقارنةً بكثير مع السردية (narrative). هل نحن نقيم السردية الخاصة بـ regulated DeFi، أم أننا نقيس ذلك بحجم الأصول الفعلية التي يتم تسويتها على السلسلة (settle)؟
#dusk $DUSK @Dusk $BTC

هناك نقطة جعلتني أتوقف عند قراءة STOX. في البداية كنت أسهل ما يكون في تصنيفه ضمن فئة DEX: مكان للتداول على الأصول على السلسلة (onchain)، لكن عند مراجعة وثائق Dusk تبيّن أن هذا الوصف بدأ ينقصه بعض العناصر.

كان STOX يُشار إليه سابقًا من قِبل Dusk كاسم داخلي مُشفّر لمنصة تداول بهدف نقل الأصول المُنظّمة إلى السلسلة وتمكين المستثمرين من التداول. حاليًا يُسمّى هذا المنتج Dusk Trade.

حاولت أن أنظر إلى ما وراء جزء التداول. لا يقتصر Dusk Trade على الحديث عن الشراء والبيع؛ فحسب الوثائق الحالية تتضمن أيضًا investor onboarding، وeligibility، وربط المحفظة، والتحويلات الخاضعة للرقابة، وتنسيق الدفعات، والتسوية.

عند هذه النقطة اضطررت إلى تعديل فهمي الأولي. يبدو أن الاختلاف لا يكمن في “وجود تداول توكنات من عدمه” بل في القواعد التي يجب أن ترافق التداول عندما تكون الأصول ذات طابع مُنظَّم.

لكنني أيضًا لا أريد المبالغة في التفسير. ما زال Dusk Trade قيد البناء، وبالتالي لا يمكنني من خلال البنية المعلنة حاليًا أن أستنتج فعاليته الفعلية في السوق.

الأمر الذي أجده أكثر جدارة بالمتابعة هو: عندما تصبح eligibility وقواعد التحويل والتسوية جزءًا من سير عمل التداول، فهل ما زال مفهوم “DEX” كافيًا لوصف هذا المنتج؟
#dusk $DUSK @Dusk $BTC

بدأتُ بقراءة Dusk Network من سؤالٍ بسيط إلى حدٍّ ما: إذا كانت RWA فعلًا ستُعرَض على بلوكتشين، فما الذي يحتاجه هذا البلوكتشين غير مجرد تسجيل التوكن؟

جعلني هذا السؤال أنظر إلى المشكلة بشكلٍ مختلف؛ فالتوكننة ليست سوى الخطوة الأولى. بعد أن يُمثَّل الأصل على السلسلة، ما زالت هناك أمور يجب التعامل معها، وهي: من المسموح له بإجراء المعاملات، وكيف تُنفَّذ المعاملات، وهل يتم مزامنة asset leg وpayment leg، وأخيرًا: أين يتم تسوية الملكية.

لذلك بدلًا من البدء من قصة: «هل Dusk هي بلوكتشين مناسبة لـ RWA؟» أردت أن أتحقق من معماريتها أولًا.

في وثائق Dusk، تتولى DuskDS إجماع الشبكة وإثبات/ضمان النهائية وتوفير توفر البيانات الخاص بـ Dusk L1، بينما توفر DuskEVM بيئة متوافقة مع EVM لتطبيقات المستخدمين.

ومن اللافت أن Dusk يصف أيضًا market infrastructure مع خطوات مثل onboarding وضوابط التحويل وتنسيق asset/payment والتسوية.

عند هذه النقطة بدأت أرى توجهًا مختلفًا: إن RWA لا تحتاج فقط إلى مكان لإصدار التوكن، بل تحتاج إلى طبقة معالجة تُدير كامل دورة حياة المعاملات. ومع ذلك ما زلت بحاجة إلى الاحتفاظ بسؤال: هل المعمارية المناسبة تعني فعلًا اعتمادًا واقعيًا؟

إذًا هل تعمل Dusk على بناء بنية تحتية للتسوية، أم أنها تبني فقط الأساس لها؟
#dusk $DUSK @Dusk $BTC

إذا كنت جديدًا على Binance P2P فهناك عادة أرى أنه من الأفضل أن تبدأ بها منذ أولى صفقاتك، ومن وجهة نظري هي ألا تختار البائع فقط لأنه يقدّم سعرًا جيدًا.

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

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

ومع ذلك هناك أمر لاحظته: هذه البيانات لا يمكنها أن تجعل الطرف الآخر “آمنًا تمامًا”، بل تساعدني فقط على امتلاك أساس إضافي للتقييم قبل تنفيذ الصفقة.

في معاملات P2P، في رأيي، ربما لا يكون الأهم هو العثور على أرخص بائع، بل تكوين عادة التحقق قبل الضغط على تأكيد.
لا أعرف إن كانت هذه الخبرات ستفيد الجميع أم لا، لكن هذا على الأقل ما خرجت به بعد أن تحققت منه بنفسي.

#binancep2pantoan @Binance Vietnam $BTC

هناك تفاصيل تجعلني مضطرًا لقراءة إجماع Dusk عدة مرات. في البداية اعتقدت أن Succinct Attestation مجرد تسمية أخرى لـ PoS، لكن التدفق الداخلي يحتوي على نقاط لافتة.

وفقًا للوثائق الحالية، يستخدم DuskDS Succinct Attestation (SA) التي يصفها Dusk بوضوح كـبروتوكول إجماع Proof of Stake قائم على لجان (committee based) وpermissionless. لكي يرغب Provisioner في المشاركة في الإجماع، يجب أن يضع حدًا أدنى قدره 1.000 DUSK كرهان.
أتابع إلى العملية. لا تكون الجولة مجرد قيام المدققين بالتصويت على كتلة، بل تُقسّم إلى ثلاث خطوات: Proposal وValidation وRatification. يقترح provisioner كتلة، ثم تقوم لجنة بالتحقق، وبعدها لجنة أخرى تُؤكد النتيجة وتُكمل الكتلة. عند اكتمال الـratification، يحقق Dusk finality حتميًا (deterministic).
عند هذه النقطة اضطررت إلى تعديل فهمي الأولي.
SA ليست “إجماعًا مختلفًا تمامًا عن PoS”. فالأساس الاقتصادي ما يزال هو الرهن (staking)، وما أعاد Dusk تصميمه يتمثل في طريقة اختيار اللجان، وفصل خطوات التحقق، وكيفية نقل الكتلة إلى الـfinality.
توقف، هذا أيضًا لا يكفي للقول إن SA أفضل من PoW أو PoS التقليديين.
يعتمد PoW على التنافس في القدرة الحاسوبية، بينما SA لا يحتاج إلى آلية من هذا النوع. لكن القول إن Dusk “يستبدل PoS بشيء جديد تمامًا” غير دقيق.
ما أراه أكثر جدارة بالبحث هو: عندما يكون الـfinality مصممًا بطريقة deterministic، فكيف يغيّر ذلك تجربة التسوية (settlement) بالنسبة للتطبيقات المالية إلى أي مدى؟
#dusk $DUSK @Dusk $BTC

هناك شيء ما جعلني أتوقف عندما كنت أقرأ عن Dusk Network. في البداية، ظننت أنها مجرد بلوكتشين مركزية تركز على الخصوصية وترميز الأصول، لكن عند مقارنة ذلك بالوثائق الجديدة، وجدت أن طريقة تحديد Dusk لمكانتها أوسع بكثير.

يصف Dusk نفسه بأنه بنية تحتية للأصول الرقمية الخاضعة للتنظيم وتمويل onchain مع تركيز على الخصوصية والتحكم في الوصول والتسوية الحتمية. هذه ليست مجرد قصة عن التوكن.
بدأت أنظر إلى بنية النظام. يتولى DuskDS آلية الإجماع والنهائية وتوفّر البيانات؛ ويقوم DuskVM بتشغيل العقود الذكية Rust/WASM مباشرة على L1؛ بينما يوفّر DuskEVM بيئة متوافقة مع EVM، باستخدام DuskDS للتسوية.

بعد ذلك تعمقت أكثر في موضوع الأصول الخاضعة للتنظيم. تشير الوثائق إلى الأهلية وربط المحفظة وقيود التحويل والإفصاح والإبلاغ والتنسيق الخاص بالتسوية. كما يتم تقسيم الخصوصية إلى مسارين: Moonlight للمعاملات العلنية وPhoenix للتحويلات المحمية (shielded).
عندها فهمت لماذا لا يكتفي Dusk بالحديث عن “إحضار الأصول إلى البلوكتشين”. إنهم يحاولون إدخال قيود السوق المالي ضمن سير العمل onchain.
لكن مهلاً، التصميم الموجه للتمويل الخاضع للتنظيم لا يعني بالضرورة أن التبني قد ثبت بالفعل.

ربما يكون السؤال الأكثر جدارة بالمتابعة هو: هل ستصبح هذه البدائيات (primitives) فعلًا بنية تحتية تستخدمها الأسواق المالية؟
#dusk $DUSK @Dusk $BTC

للوهلة الأولى، كنت أعتقد أن باينانس P2P لا تضيف سوى بضع طبقات إضافية من الحماية للمعاملات من نظير إلى نظير. وكان الإسكرو (الضمان) والتحقق أو الـ Appeal (الاستئناف) مفاهيم مألوفة إلى حد ما.

لكن كلما قرأت بتأنٍ أكثر، أدركت أن المشكلة أكثر إثارة للاهتمام وتتمثل فيما يحدث عندما لا يعود الطرفان متفقين على تفاصيل المعاملة.

في البداية افترضت أن الدردشة (Chat) وAppeal مجرد أدوات مساعدة عند حدوث خلل، ثم اتضح لي أن قيمتهما تكمن في تمكين الطرفين من تقديم المعلومات والأدلة لكي تراجع باينانس الأمر عند نشوء نزاع.

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

ما شغلني مجددًا هو سلوك المستخدمين. توصي باينانس أيضًا بعدم الاعتماد على الصور أو رسائل SMS للتحقق من الدفع، وبأن يتم الاحتفاظ بالمستندات عند الحاجة إلى Appeal.

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

وكلما فكرت أكثر، شعرت أنها أقرب إلى نموذج للتنسيق (coordination) منها إلى مجرد ميزة، وربما لا تتجلى قيمة البنية التحتية (infrastructure) إلا عندما لا تصبح المعاملة بسيطة.
#binancep2pantoan @Binance Vietnam $BTC

هناك مكان يجعلني مضطرًا لإعادة القراءة عند التعرف على Dusk Network. كنت أعتقد سابقًا أن الترميز (tokenization) أمر بسيط إلى حد ما، وهو: أخذ أصل، وإنشاء توكن يمثل هذا الأصل، ثم رفع التوكن إلى البلوك تشين.
لكن وثائق Dusk تُعرّفه بشكل أدق. الترميز (Tokenization) هو عملية إصدار توكن يمثل أصلًا أو حقًا متعلقًا بهذا الأصل. المشكلة هي أنه بالنسبة للأصول المُدارة، وعمليات الحفظ (custody) والسجل (registry) والتسوية (settlement) قد تظل خارج الدفتر (ledger).

بدأت أنظر إلى باقي مراحل دورة الحياة: الإصدار (issuance)، والأهلية (eligibility)، وقيود التحويل (transfer restrictions)، والإفصاح (disclosure)، والتداول (trading) والتسوية (settlement). وهذه أيضًا هي مسارات العمل (workflows) التي أدخلها Dusk ضمن تصميم بنية البنية التحتية للسوق (market infrastructure).
يتولى DuskDS مسؤولية التسوية (settlement) والنهائية (finality) وتوافر البيانات (data availability). توفر Citadel الهوية (identity) والإفصاح الانتقائي (selective disclosure). يقع Dusk Trade ضمن طبقة التطبيق (application layer)، ويعالج مسارات العمل مثل بدء الاستخدام (onboarding) والتداول (trading) وتنسيق تسوية الأصول مقابل المدفوعات (asset-payment settlement).

اتضح أن النقطة التي أغفلتها في البداية لم تكن التوكن نفسه، بل ما يحدث قبل وبعد كل عملية نقل (transfer).
مهلًا، هذا لا يعني أيضًا أن كل شيء يتم تلقائيًا على السلسلة (onchain)؛ فحتى الوثائق نفسها توضح أن بنية Dusk المحددة تعتمد على المنتج والمتطلبات القانونية.

لذلك تغيّر طريقتي في فهم Dusk قليلًا: فالترميز هنا لا يقتصر على إنشاء تمثيل (representation)، بل يتعلق ببناء كامل مسارات العمل حول الأصل.
ففي النهاية، أين تكمن القيمة: في التوكن أم في البنية التحتية التي تجعل ذلك التوكن قابلًا بالفعل للتشغيل؟
#dusk $DUSK @Dusk $BTC

في إحدى المرات قدمتُ طلبًا عبر P2P ثم لاحظت أن طريقة الدفع غير مناسبة، فقررت إلغاءه. كنت أظن أن الأمر مجرد إجراء طبيعي، إلى أن تساءلت: إذا كان بإمكان أي شخص إلغاء الطلب كما يشاء، فعلى أي أساس تعتمد Binance لتقييم التاجر (merchant) باعتباره موثوقًا؟
سابقًا كنت أرى أن إلغاء الطلبات أمر بسيط؛ فإذا لم أعد أريد إتمام الصفقة فأسقطها بالإلغاء. لكن عند مراجعة وثيقة Binance P2P Merchant Guidelines، بدأ هذا التصور يتغير.

توضح Binance صراحةً أن التاجر لا يجوز له “cancel orders arbitrarily” (إلغاء الطلبات بشكل تعسفي). وفي الوقت نفسه، يُعد معدل إتمام الطلبات خلال 30 يومًا أحد المؤشرات المستخدمة لتقييم التاجر؛ إذ قد تؤدي معدلات الإتمام المنخفضة إلى استبعاده من برنامج التجار.

تابعت قراءة قسم مبادئ التداول لأرى ما إذا كانت Binance تمنع الإلغاء بشكل مطلق. لا، فالمستند يذكر حالات يمكن فيها للتاجر إلغاء الطلب، مثل عدم استيفاء معلومات حساب الدفع الخاصة بالطرف الآخر للمتطلبات أو قيام المستخدم برفض بعض خطوات التحقق الإضافية.

عندها اضطررت إلى تعديل فهمي الأول.
المشكلة ليست في أن “إلغاء الطلب خاطئ”. المشكلة في كلمة “تعسفي”. إن Binance تميّز بين وجود سبب صحيح لإنهاء الصفقة وبين إلغاء الطلب دون أساس.
لحظة، هذا أيضًا لا يعني بعد أن الإلغاء مرة واحدة سيؤدي حتمًا إلى عقوبة. يتناول المستند معايير التقييم وحالات المخالفة، وليس الأمر ببساطة أن الضغط على زر الإلغاء مرة واحدة يعني تلقائيًا اتخاذ إجراء.
قد يكون الأهم من ذلك: في نظام P2P، إجراء يبدو صغيرًا جدًا يُضمَّن داخل نظام تقييم كامل لمستوى إتمام الطلبات ودرجة موثوقية التاجر.

#binancep2pantoan @Binance Vietnam $BTC

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

حاليًا، يصف Dusk الخصوصية عبر ثلاثة محاور: الحساب العام عبر Moonlight، والمعاملات المُحمّاة (shielded) عبر Phoenix، والإفصاح الانتقائي عندما يحتاج طرف مُفوَّض إلى دليل.

غصت في Citadel لأن الوثائق تحدد أنه طبقة الهوية وإدارة الوصول الخاصة بالإفصاح الانتقائي. يستخدم Citadel إثباتات عدم المعرفة (zero knowledge proofs) لكي يتمكن المستخدم من إثبات أنه يمتلك ترخيصًا صالحًا دون الحاجة إلى الإعلان عن جميع بيانات الهوية.

واللافت للنظر يكمن في هذه النقطة: على سبيل المثال، لا تتحدث الوثائق عن "الكشف عن الهوية بالكامل". يقوم المستخدم بإنشاء الدليل (proof)، ثم يقوم مزود الخدمة بالتحقق من صحة الصلاحية عبر عملية Citadel.
توقفوا لحظة—هذا لا يعني بعد أن كل البيانات على Dusk يتم تلقائيًا الكشف عنها بشكل انتقائي. فالوثائق لا تصف إلا اللبنات الأساسية والأنماط (primitives وpattern) التي يمكن للتطبيقات البناء عليها لإنشاء سير عمل مناسب.

ربما هذه هي النقطة التي كان يجب أن أحتفظ بها: الإفصاح الانتقائي في Dusk ليس "خصوصية لكن مع زر يجعلها عامة"، بل هو طريقة لفصل صلاحية إثبات معلومةٍ ما عن عملية الإعلان عن جميع المعلومات.

إذًا، السؤال التالي سيكون أكثر إثارة للاهتمام: إلى أي مدى يتم تطبيق هذه اللبنات الأساسية (primitives) في التطبيقات العملية؟
#dusk $DUSK @Dusk $BTC

هناك موقف بسيط إلى حد ما جعلني أغيّر طريقة تفكيري في اختيار الشركاء على Binance P2P.

لنفترض أنني أحتاج إلى شراء 1.000 USDT وألاحظ أن هناك إعلانين بسعرين متقاربين جدًا. لقد أنهى الشخص A حوالي 2.800 معاملة، ونسبة الإكمال لديه 99,6%. أما الشخص B ورغم أن سعره أفضل، إلا أنه أتم فقط 45 معاملة ونسبة الإكمال لديه 91%.

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

إن 2.800 معاملة لا تثبت بالضرورة أن الشخص A لن يواجه أي مشكلة، لكنها تمنحني كمية أكبر من البيانات التاريخية لتقييم الوضع. في المقابل، فإن 45 معاملة ونسبة إكمال أقل تعطيّني أساسًا أقل للاعتماد على استقرار الطرف الآخر.

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

لن أعتبر نسبة الإكمال أو عدد المعاملات بمثابة تذكرة ضمان. إنها فقط تمنحني مزيدًا من الأساس لاتخاذ القرار، بينما يبقى التحقق من الصفقة المحددة مسؤولية تقع عليّ أنا.
#binancep2pantoan @Binance Vietnam $BTC

هناك تفصيل واحد جعلني أعود لقراءة بنية Dusk مرة أخرى. في البداية اعتقدت أن DuskDS ليست سوى الجزء الخاص بسلسلة الكتل الموجود أسفل DuskEVM لكن الوثائق التقنية تصفه بشكل أوسع من ذلك.

يُعرَّف DuskDS بأنه طبقة التسوية وتوفّر البيانات الخاصة بـ Dusk L1، وهو المسؤول عن الإجماع والنهائية ونماذج المعاملات الأصلية. DuskEVM هي طبقة التنفيذ التي تستخدم DuskDS للتسوية وتوفّر البيانات. أما DuskVM فيقوم بتنفيذ العقود مباشرةً على Dusk L1.

غصتُ أكثر في كيفية التحقق من التسوية فعليًا. يستخدم DuskDS Succinct Attestation، وهي آلية إثبات بحصة (Proof-of-Stake) مبنية على لجنة. تتضمن العملية اقتراحًا ثم تحققًا ثم مصادقة نهائية (ratification)، وعندما تتم مصادقة الكتلة تكون النهائية حتمية.

بعد ذلك نظرت إلى نموذج المعاملات. يتعامل Moonlight مع الحسابات العامة بينما تستخدم Phoenix ملاحظاتٍ مخفية (shielded notes) وإثباتات المعرفة الصفرية. نموذجَان مختلفان لكن في النهاية كلاهما تتم تسويته على نفس السلسلة.
مهلًا، هذا لا يعني أن DuskDS يتولى وحده كامل منطق التطبيق. ما زال التنفيذ من مسؤولية DuskVM أو DuskEVM، لكن هذا تحديدًا جعلني أغيّر طريقة تفكيري: إن Dusk يفصل التنفيذ بشكل واضح إلى حد كبير عن التسوية.

إذاً، لم يعد السؤال الذي يستحق المتابعة هو ما إذا كان DuskDS طبقة تسوية أم لا، بل: كيف ستحدث هذه البنية التي تفصل التسوية فرقًا عمليًا عندما تبدأ التطبيقات المالية بالعمل على نطاق كبير؟
#dusk $DUSK @Dusk

هناك موقف كنت أعتقد أن المبتدئين كثيرًا ما يواجهونه عند بيع USDT على Binance P2P، وقد واجهته أنا أيضًا.
حدثت مرة أنني قمت بإعداد طلب بيع بـ 350 USDT. أبلغني المشتري أنه قد قام بتحويل الأموال وكتب فورًا: “تحقق من فضلك وخلّي تِ release، أنا محتاج USDT بسرعة.”

بعد فترة وجيزة أرسل لي صورة تُظهر نجاح عملية التحويل البنكي. فتحت الصورة ونظرت إلى مبلغ المال والوقت واسم المستلم. بدا كل شيء منطقيًا، لكن عندما فتحت تطبيق البنك الخاص بي مباشرة، لم تكن الأموال قد ظهرت بعد.

سأنتظر حتى تظهر الأموال فعليًا في حساب المستلم بدلًا من أن تحدد استعجال الطرف الآخر توقيت الـ release.
قد يكون المشتري صادقًا تمامًا، وقد يكون التحويل البنكي فقط متأخرًا.

أريد أن أعرف هل هذا الضغط يغيّر بالفعل الإجراء.
عند مراجعة الوثائق، وجدت أن Binance توصي بالحفاظ على المحادثة داخل المنصة، والتحقق من الأموال مباشرة في حساب الاستلام، وعدم الاعتماد على لقطات الشاشة أو الرسائل النصية القصيرة أو تأكيدات الطرف الآخر لإتمام عملية release. إذا وُجدت مشكلة، يمكن إدخال المعاملة في appeal وتقديم الأدلة.

لكن لحظة، هذا لا يعني أن كل من يستعجل هو بالضرورة عملية احتيال. ربما كانوا فقط يريدون إتمام الصفقة بسرعة، لكن هنا بالذات لاحظت شيئًا مهمًا: الـ escrow يحمي الأصول، لكنه لا يُغني عن خطوة التحقق من المستخدم.

وبالنظر إلى الصورة الأوسع، يظل P2P عملية فيها جانب يدوي إلى حد ما، لذلك يبقى الضغط البشري دائمًا موجودًا.

لذلك لن أترك استعجال الطرف الآخر هو الذي يحدد سير المعاملة؛ لن أُفعل الـ release إلا عندما تدخل الأموال فعليًا إلى حسابي. قد أكون حذرًا أكثر من اللازم، لكن في P2P، الحذر أفضل من الوثوق بشيء لم أتحقق منه.

#binancep2pantoan @Binance Vietnam $BTC

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

أعدتُ قراءة بنية النظام ولاحظت أن DuskDS يدعم نموذجين مختلفين تمامًا للمعاملات. Moonlight هو نموذج عام، بينما يستخدم Phoenix ملاحظاتٍ محمية واثباتات معلومات صفرية لإخفاء مبلغ المعاملة، أو المُرسِل، أو أي علاقة بين الملاحظات.

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

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

إذا كان الأمر كذلك، فالسؤال الذي أود مواصلة التحقق منه هو: في التمويل المُنظّم، متى تكون الخصوصية ذات قيمة فعلًا—عندما يلزم حماية البيانات، أم عندما يلزم الإفصاح عنها للجهة المناسبة؟
#dusk $DUSK @Dusk

لقد واجهت ذات مرة موقفًا اضطرّني لإعادة قراءة إجراءات Binance P2P. كان ذلك عندما بعت 200 USDT بعد أن حصلت على airdrop من Binance Alpha. أرسل المشتري لي لقطة شاشة تفيد بأنه تم تحويل المبلغ، ودفعني إلى إصدار/Release للعملات المشفرة. للوهلة الأولى، بدت الأمور طبيعية، لكن عندما تحققت مباشرةً من حساب الاستلام، اتضح أن هذا المبلغ لم يظهر على الإطلاق. ومن خلال هذا الموقف بدأت أولي اهتمامًا أكبر لتفصيل في إرشادات Binance: يجب على البائع ألا يقوم بعمل Release للعملات المشفرة إلا بعد أن يتحقق بنفسه من أنه قد استلم فعليًا المال.

قرأت إرشادات Binance مرة أخرى ولاحظت أن العملية واضحة جدًا. عند البيع، تُحفظ العملات المشفرة في escrow. ينتظر البائع وصول الدفع إلى وسيلة الدفع المتفق عليها، ثم يؤكد أنه قد استلم المال بالفعل، وبعد ذلك فقط يقوم بإصدار/Release.

أريد أن أفهم لماذا تم وضع خطوة “التأكيد” قبل خطوة “Release” بدلًا من الاعتماد فقط على إشعار “تم الدفع”.

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

وبالنظر بشكل أوسع، يتحمل المستخدم دائمًا جزءًا من المسؤولية في P2P. ربما في P2P، لا تكمن السلامة في الاعتقاد بأن النظام قد تعامل مع جميع المخاطر، بل في أن تظل أنت تتحقق مما لا يستطيع النظام تأكيده نيابةً عنك.
#binancep2pantoan @Binance Vietnam $BTC

هناك شيء ما جعلني أتوقف عندما قرأتُ معمارية Dusk Network. في البداية كنت أراها كأي Layer 1 مألوف: فيها consensus، وsmart contract، وtoken، ونظام بيئي مبني فوقها.
لكن عندما قرأتُ بتمعّن أكثر، جعلتني طريقة Dusk في تقسيم المكوّنات أعود وأقرأ من البداية.

تصف وثائق Dusk أن DuskDS هي منصة settlement وdata availability، وهي المسؤولة عن consensus وfinality وtransaction model الخاص بـ Dusk L1، بينما يتم فصل execution إلى اتجاهين: DuskVM لتشغيل Rust/WASM مباشرة على L1، وDuskEVM لبيئة EVM المتوافقة مع Ethereum.

بدأتُ أبحث بعمق لأنني أردت أن أفهم هل هذا مجرد إعادة تنظيم لـ Layer 1 أم أنه يعكس فعلاً اختيارًا معماريًا مختلفًا.
النقطة التي وجدتها واضحة جدًا: Dusk لا يجمع كل execution داخل بيئة واحدة. DuskDS تتولى consensus وsettlement وdata availability، بينما تتكفل DuskVM وDuskEVM بنماذج execution مختلفة.

انتظر، هذا لا يزال غير كافٍ للقول إن هذه المعمارية أفضل، لكنه يغيّر الطريقة التي أنظر بها إلى Dusk. ربما السؤال الأكثر إثارة ليس: "هل Dusk هي Layer 1 أم لا؟" بل: ماذا سيُضيف فعليًا فصل settlement عن execution عندما تبدأ بيئات التنفيذ هذه بالحصول على usage ملحوظ؟

#dusk $DUSK @Dusk $BTC

ذَكْرَةُ ذات مرة أنني بعت عملات كريبتو على Binance عبر P2P. أخبرني المشتري أنه قد أرسل التحويل وشارك صورة تُظهر أن العملية قد اكتملت بنجاح. نظرتُ إلى ذلك فبدت الأمور وكأنها انتهت تقريبًا، لكن عندما فتحت تطبيق البنك للتحقق، لم تظهر الأموال بعد في حسابي. توقفت عند هذه النقطة بدل أن أضغط على زر Release، لأن سؤالًا أصبح واضحًا جدًا: إذا كان المشتري قد قال “تم التحويل”، فما الشيء الذي أحتاج لتأكيده قبل أن يتم فعليًا تحرير الكريبتو للمشتري؟

جرّبتُ التفكير عكس ذلك عبر معاملة بسيطة. قام المشتري بالدفع بالطريقة المتفق عليها، ثم تحقق البائع من الأموال المستلمة. توضح وثائق Binance بوضوح أنه بعد تأكيد وصول الأموال إلى البائع فقط يتم تحرير الكريبتو من الـ escrow.

أردت أن أفهم لماذا وُضِعَت خطوة التأكيد هذه على عاتق البائع.

عندما قرأت Merchant Guidelines، وجدت أن Binance تتطلب أيضًا أن يكون الاسم على حساب الدفع مطابقًا للاسم الذي تم التحقق منه على المنصة. إذا لم تتطابق معلومات حساب البنك الخاصة بالطرف الآخر مع الاسم الذي تم التحقق منه في Binance، فسيُطلب عدم تحرير الكريبتو؛ ويمكن للبائع إما إرجاع المبلغ وإما الإبلاغ عن المعاملة.

عندها فقط أدركت أنني كنت أنظر إلى P2P بطريقة مبسطة. الـ escrow يحتفظ بالعملة الكريبتو أثناء سير المعاملة، لكن تأكيد أن الدفع قد تم استلامه فعليًا يبقى خطوة منفصلة داخل الإجراء.

انتظر… هذا لا يعني أن Binance يمكنها منع كل مخاطر الدفع. الوثائق تشير فقط إلى أن مسؤولية التحقق من الأموال ومن معلومات المُرسل لا تزال موجودة قبل تحرير الكريبتو.

ربما لا تعني كلمة “Release” تأكيد وصول المال، بل هي الخطوة التي تُنفَّذ بعد اكتمال التأكيد.
لذلك قبل الضغط على Release يجب التأكد بعناية من كل شيء من فضلكم.
#binancep2pantoan @Binance Vietnam $BTC

هناك شيء ما يجعلني أتوقف عند قراءة معلومات عن شبكة Dusk: يتم وصف DuskDS وDuskEVM كجزئين مختلفين، لكنهما لا يقفان منفصلين.

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

أريد التحقق مما إذا كان هذا مجرد تسميات ذات طابع معماري أم أنه يعكس بالفعل فصلًا في المسؤوليات.
عند التعمّق أكثر، ألاحظ أن DuskDS يتولى معالجة الإجماع والنهائية والتوافر للبيانات، إلى جانب نماذج المعاملات مثل Moonlight وPhoenix. يركّز DuskEVM على جانب التنفيذ، ويمكّن من استخدام Hardhat وFoundry مع نظام بيئي لـ EVM. جهة توفّر أساس التسوية، والأخرى تتولى التنفيذ.

لحظة، هذا لا يزال غير كافٍ للقول إن طبقتين “داعمتين” لبعضهما بالمعنى المتعلق بالأداء أو الأمان. ومن الوثائق التي تحققت منها، فإن أوضح علاقة هي أن التنفيذ منفصل عن التسوية.
الأمر المثير للاهتمام هو أن Dusk يستخدم modularity لفصل التسوية بشكل مستقل، لكنه يظل منفتحًا على المطورين عبر EVM.
فإذا زادت تبني التطبيقات، فهل حقًا يخلق هذا الفصل بين التنفيذ والتسوية ميزة، أم أنه ببساطة طريقة لتنظيم البنية المعمارية؟
#dusk $DUSK @Dusk $BTC